-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Build: install all the latest Python "core requirements" #10508
Conversation
I created a new feature flag called `INSTALL_LATEST_CORE_REQUIREMENTS` that does not depend on any other feature flag. Its goal is to always install the latest Python packages. We are trying to move away from pinning the dependencies on our side and telling users to do that on their side if they want to have reproducible builds over time. I think this is the best outcome for new projects since they will immediately use the latest versions of everything instead of old (and maybe broken) dependencies. I propose to set a particular date for this feature flag and make new projects to start building with all the latest dependencies. This will, at least, stop making the problem bigger. Later, we can decide how to communicate to old projects that we are going to install the latest requirements and if they don't want that, they should pin their dependencies. We can follow our new and shiny deprecation path we have built and tested in the last month. Related readthedocs/meta#8 Related #9562 Related #10402 Related #9081
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 makes a ton of sense to me, to get things on a good state for new projects, and then work backwards for old projects to move to this state 👍
@@ -56,20 +56,25 @@ setuptools: | |||
All other projects use the latest version. | |||
|
|||
mock: | |||
``1.0.1`` (could be removed in the future). | |||
``1.0.1``. | |||
Projects created after August 7, 2023 won't install this dependency by default. |
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 don't think this will break anything, since it's for new projects, so I'm fine doing it sooner.
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 targeted this for next month to give us some time to review the PR, make the adjustments, etc and maybe write a pretty small changelog blog post announcing this so we have something to link people to when they ask.
Do not install `sphinx-rtd-theme` and clarify the docstring.
Are we OK moving one step forward?:
Is this too much? 💣 Is this the goal we want to reach eventually? If that's the goal, are we OK with this intermediate step where we are removing most of the core dependencies but not the doctools? |
I think we probably want to keep installing the actual build tool, since they are configuring it in the config file. If folks don't want anything installed, they can use I don't feel super strongly though. The number of projects that just want Sphinx, and no extensions seems pretty low, but like a reasonable thing to support out of the box? Otherwise, we need to start requiring a requirements file, or a supported way to pin dependencies in the RTD YAML, and validating the build tool is installed, and that seems like a larger step. |
Yeah, good point. I think it's fine to keep installing those for now. We can re-think this in the feature if required and when we are more prepared to do this step. |
Announce the changes made at readthedocs/readthedocs.org#10508 Note that we are not exposing this feature flag to our users. We don't want them to contact us to enable this flag. If they need to install the latest versions they can just specify them in their `requirements.txt` file.
* Post: small post about "latest core requirements" Announce the changes made at readthedocs/readthedocs.org#10508 Note that we are not exposing this feature flag to our users. We don't want them to contact us to enable this flag. If they need to install the latest versions they can just specify them in their `requirements.txt` file. * Update python-core-requirements-changed.rst Co-authored-by: Eric Holscher <[email protected]> * Update python-core-requirements-changed.rst --------- Co-authored-by: Eric Holscher <[email protected]>
@ericholscher this PR is ready for re-review. This is the new behavior: |
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.
Looks good to me 👍
This is the new behavior and where we are moving towards. | ||
""" | ||
# First, upgrade pip and setuptools to their latest versions | ||
cmd = pip_install_cmd + ["pip", "setuptools"] |
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 do think upgrading pip & setuptools will definitely cause us issues when they ship busted versions, but hopefully that will teach users to pin their deps! 🗡️
I created a new feature flag called
INSTALL_LATEST_CORE_REQUIREMENTS
that doesnot depend on any other feature flag. Its goal is to always install the latest
Python packages.
We are trying to move away from pinning the dependencies on our side and telling
users to do that on their side if they want to have reproducible builds over
time.
I think this is the best outcome for new projects since they will immediately
use the latest versions of everything instead of old (and maybe broken)
dependencies.
I propose to set a particular date for this feature flag and make new projects
to start building with all the latest dependencies. This will, at least, stop
making the problem bigger. Later, we can decide how to communicate to old
projects that we are going to install the latest requirements and if they don't
want that, they should pin their dependencies. We can follow our new and shiny
deprecation path we have built and tested in the last month.
Related readthedocs/meta#8
Related #9562
Related #10402
Related #9081
📚 Documentation previews 📚
docs
): https://docs--10508.org.readthedocs.build/en/10508/dev
): https://dev--10508.org.readthedocs.build/en/10508/