-
Notifications
You must be signed in to change notification settings - Fork 11
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
batou 2.5.0b3 has requirement setuptools>=66.1.0, but you have setuptools 65.5.0.
#466
Comments
Hmm, with Python 3.12 and batou 2.5b3 I get
The
Guess I'll do |
What are the preferred python versions? The bootstrapping mechanism should only trigger when |
No preferences specified. Confirmed that prepending ( |
Yes, we probably should create and merge https://github.com/flyingcircusio/appenv/compare/pip-freeze-all-package-regardless-of-version?expand=1 I'd love to merge https://github.com/flyingcircusio/appenv/compare/venv-create-update-deps?expand=1 but upgrade_deps was added in python 3.9 :/ |
It looks like https://github.com/python/cpython/blob/3.11/Lib/ensurepip/__init__.py#L13 got us into this mess. When creating a venv, ensurepip is used to install pip (and setuptools as a pip dependency) |
Should be closed by #55 |
With batou 2.5.0 I still get
while deploying. Python is Python 3.11.9. |
Manually adding e.g. |
Sounds like underspecified dependencies somewhere then. I don't think we should maintain a setuptools dependency in our deployments. |
I suggest we move further discussion to flyingcircusio/appenv instead since it appears the lockfile does not include setuptools by default |
After the update to the new appenv version, did the lockfile get rebuilt? |
Just checked, this error resolves once the lockfile is rebuilt using We could
@Ma27 @PhilTaken what do you think of each of the solutions? |
Yes indeed. So what I think happened was
Personally, I'd prefer the latter option. Though, connecting the lockfile to appenv seems kinda orthogonal to the second approach: maybe we also want that since it generally seems a little more robust (however not as important to implement with (2) being done). |
I would strongly argue in favor of the first option. It does not impact lockfile updates unless you update appenv, in which case you might as well update the requirements anyways - and should, as we can see here. Running an appenv-specific update script is error-prone (pebcak) and tedious with no way to even tell if it has been run unless you also tack the appenv version into the lockfile at which point you've just implemented a worse version of the first option. |
It's a good point that you'll probably need option 1 to correctly implement option 2. If that's actually the case, I fully agree. My point is mostly motivated from the fact that I'd expect an auto-updater to be easier to use as end-user here. Anyways, there are issues for both things, so this can be closed for good :D |
Given
69.5.1.post0
)I get the following error when running
./appenv python
:Workaround for me was
nix shell nixpkgs#python312
.I assume this is because
appenv
bootstraps itself from https://www.python.org/ftp/python/3.11.9/Python-3.11.9.tgz which has a setuptools 65.5.0 bundled.If I understand the issue correctly, the bump of setuptools to 66.1 breaks most of the Python versions supported by batou because of the way appenv works.
cc @zagy @elikoga
The text was updated successfully, but these errors were encountered: