-
Notifications
You must be signed in to change notification settings - Fork 327
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch to sphinx-theme-builder
and improve webpack.config.js
#514
Switch to sphinx-theme-builder
and improve webpack.config.js
#514
Conversation
Hehe, I goofed up Python 3.7 support. |
It seems like the linting changes are gonna create a big diff...maybe we could do that one as a separate PR so that it is easier for others to review the theme builder update? |
Either way, this PR is going to be easiest to review commit-by-commit. |
ac502f7
to
1f5bcc9
Compare
sphinx-theme-builder
and improve webpack.config.js
de0dc70
to
731d673
Compare
\o/ The documentation build works! https://pydata-sphinx-theme--514.org.readthedocs.build/en/514/ |
The interpreter goes EoL in ~1 month, and it is not supported by `sphinx-theme-builder`.
Restructure the repository to be compatible with `sphinx-theme-builder` and switch away from setuptools. This enables excluding the generated assets from version control, since `sphinx-theme-builder` will generate them, when generating the wheel. Replace the usage of `yarn` with vanilla `npm`, to be more compatible with `sphinx-theme-builder`, and for reducing the complexity in the setup. Explicitly declare that this theme uses the latest 14.x LTS release of NodeJS. Simplify `noxfile.py` since it is no longer necessary to use conda for fetching the theme's non-Python dependencies. It happens transparently in a `pip` based workflow. Use `stb serve` for serving documentation, in `noxfile.py`. Move `flake8` configuration into a flake8-specific file.
Realistically, users should be using sphinx-build directly OR use the nox targets to generate the documentation.
This will hopefully save someone a Google search.
Utilise a dedent helper, and include the hash as a digest query parameter.
364e940
to
bd6168b
Compare
Hehe, codecov is complaining because I removed lines, reducing the coverage %age. 😆 |
Most of the changes here now, are either:
|
😅 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pradyunsg thanks a lot for this effort! This is really great
Tried it out locally, easy to set up and use, everything went smooth (except I first forgot to install the package again before calling stb serve
)
Added a few inline comments/questions. And two additional things:
- The "Publish to PyPI" will still need to be updated I suppose? (we are using, ahum,
setup.py dist bdist_wheel
.. 🤦) That should be a simplestb package
? - The contributing.rst will need some more updates (but I am also happy to take a look at this in a follow-up)
"-n", "-b", "html", "docs/", "docs/_build/html" | ||
) | ||
# fmt: on | ||
session.install("sphinx-theme-builder[cli]") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this also need a session.install(".[doc]")
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that the theme builder will automatically handle the dependencies of the local theme so we don't need to explicitly install it here, but maybe @pradyunsg can confirm that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does need that line. I missed it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I can confirm this is needed but I guess we can fix it in a follow-up PR.
@damianavila @choldgraf any comments / concerns here, or shall I go ahead and merge this (and update the other PRs) |
|
||
# Build docs on a number of Python versions. In the future this can be | ||
# where tests go. | ||
tests: | ||
runs-on: ubuntu-latest | ||
strategy: | ||
matrix: | ||
python-version: [3.6, 3.7, 3.8, 3.9] | ||
python-version: [3.7, 3.8, 3.9] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we should also add 3.10 now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO we should add that explicitly in a separate PR, because we don't know if this might break something. I feel more comfortable about dropping supported versions as a side-effect, rather than adding them :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough ;-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me, provided that there are no objections to the outstanding comments. I think it's a much cleaner workflow once we get the hang of it, and I am thrilled that we will no longer have merge conflicts for the hashes every time somebody merges some CSS/JS :-)
Next steps
How about this plan:
- Leave this open for a day to see if @damianavila has any comments he think should block merging for now.
- If not, or @damianavila has ideas but that don't need to block a merge, then we just merge this one in and iterate in subsequent PRs.
|
||
# Build docs on a number of Python versions. In the future this can be | ||
# where tests go. | ||
tests: | ||
runs-on: ubuntu-latest | ||
strategy: | ||
matrix: | ||
python-version: [3.6, 3.7, 3.8, 3.9] | ||
python-version: [3.7, 3.8, 3.9] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just want to highlight that we're dropping Python 3.6 support here, in case anybody has a strong objection. I think it is fine because it will no longer have official support soon anyway, but just making it clear here.
"-n", "-b", "html", "docs/", "docs/_build/html" | ||
) | ||
# fmt: on | ||
session.install("sphinx-theme-builder[cli]") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that the theme builder will automatically handle the dependencies of the local theme so we don't need to explicitly install it here, but maybe @pradyunsg can confirm that?
I just left some tiny comments 😉 ! |
We can certainly leave it open for a day longer if that helps (and much appreciated you want to test drive this thoroughly, @damianavila!). But I think most feedback we (will) have here is good as follow-up PRs anyway. Merging this PR sooner rather than later / addressing those comments in follow-ups will make it easier to actually test those new workflows by using them while working on the theme. The noxfile is also still quite new anyway, and will have to settle down a bit (I am also not sure what eg the benefit of |
Given that @jorisvandenbossche is a conda person and still thinks that the workflow here is reasonable (potentially could be documented more cleanly, but we can do that in follow up PRs), I'd be +1 on merging after 24 hours so that we can move forward. For remaining review here, I think we should focus on major changes that might need to be made, but handle smaller details, docs, etc in follow-ups after we've had a chance to work with it. |
Update: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, everyone, I think now I have a clear understanding of what is happening here 😉
I have tested the PR successfully except for the docs-live issue referenced above that can be fixed in a follow-up PR.
It is interesting to notice how layered we would be from now on the JS side of things (and from the development point of view):
- nox
- stb
- npm
We would need some docs updates on nox
and new stuff for the stb
.
Wondering if it makes sense to go deeper (or not) since we are aiming at "python devs that need JS stuff"... but we can talk about that later.
LGTM to merge this one as is 😉 and iterate on follow-ups.
wohoo! I'll merge this one in now! @jorisvandenbossche wanna give a rebase in #436 ? |
I'm seeing a few follow ups here. Does someone else want to file issues to track that they get done? |
I think the follow-ups are:
For the first + last one I will directly do a PR, and will open an issue for the docs. |
And thanks a lot @pradyunsg once more! This is a wonderful tooling improvement! |
You can see more details in the following comment: #514 (comment)
More details are available here: pydata#514 (comment)
I think that was resolved in #519 although I had some question there after the PR was merged.
I quickly opened a PR for this one: #520.
I also captured this one in a new issue: #521. |
Closes #503.
This is going to be easiest to review commit-by-commit, where each commit has a clear description of why the changes were made.