Skip to content

Conversation

@ericholscher
Copy link
Member

@ericholscher ericholscher commented Nov 21, 2024

This is just a starting point with a generic config.

Fixes #301


📚 Documentation preview 📚: https://readthedocs-about--337.org.readthedocs.build/

This is just a starting point with a generic config.

Fixes #301
# rust: "1.70"
# golang: "1.20"

commands:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is probably a case for using build.jobs.build.html

Copy link
Member Author

@ericholscher ericholscher Dec 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That doesn't currently work for non-Sphinx/Mkdocs currently (readthedocs/readthedocs.org#11810), and I think the goal of this page is to promote custom commands, so I think build.commands is fine for now.

# golang: "1.20"

commands:
# Python
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indentation is too far over here

- cd docs/ && npm run build
# Copy generated files into Read the Docs directory
- mkdir --parents $READTHEDOCS_OUTPUT/html/
- cp --recursive docs/build/* $READTHEDOCS_OUTPUT/html/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should use the JS example over the Sphinx example, an unsupported tool would be even better to illustrate.

<i class="fad {{ icon_3 }} secondary big icon"></i>
<span class="content">
{{ header_3 }}
<span class="sub header">Copy this example, it probably does what you want 😉</span>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given our generic project example, I wouldn't suggest users copy this.

@ericholscher
Copy link
Member Author

Should be ready to merge, if we want. I don't think this will generate much SEO value, but I think it's important to start conveying we can support any tool.

@ericholscher
Copy link
Member Author

Would love another review to get this out 👍

Copy link
Member

@humitos humitos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine merging this PR for now. However, I really want to talk more about our marketing pages and review what I said in #336 (review) and also in #307. The later is new content that I think we are currently missing.

I think we need a good re-structure and simplification of all these pages, so we don't keep adding more and more content because our current pages don't solve the problem. I really think we should have a lot fewer pages here with more concrete content that point users to our documentation pages for specific build options.

@ericholscher
Copy link
Member Author

@humitos Agreed -- I think we can use the docs for more of the iteration of various tools that we support. The docs have better SEO in general anyway, and the website can just have a listing. I'm imagining something like https://www.ethicalads.io/advertisers/#audiences but with a listing of supported tools linking to nice docs pages?

But I do think it's important if we're gonna have a Tools section of the site to make sure we explicitly note supporting other tools. If we want to refactor the Tools section as a next step, I'm 💯 on that.

@ericholscher ericholscher merged commit 2c814d6 into main Dec 11, 2024
4 checks passed
@ericholscher ericholscher deleted the generic-tool branch December 11, 2024 22:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Write page for "Other / Generic" support tool

3 participants