-
-
Notifications
You must be signed in to change notification settings - Fork 611
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
keep order in requirements.in #992
Comments
To offer an alternative perspective, maybe |
To be clear, Considering that, I'm not in favour of adding features that encourage relying on the declaration order in the requirements file. @AndydeCleyre suggestions makes sense, and is the right way to go right now IMO. @pradyunsg May I shamelessly summon your knowledge to consider what would be the order in this case above? -- |
Are you sure? I have a tiny package with some optional dep groups and it doesn't seem to mark the optional deps as top-level. Without any optional dep groups:
ptrender
plumbum==1.6.8 # via ptrender
ptrender==0.0.3 # via -r requirements.in (line 1)
pyratemp==0.3.2 # via ptrender With one optional dep group (that just directly adds the dep
ptrender[yaml] $ grep '^strictyaml' requirements.txt
strictyaml==1.0.6 # via ptrender With more (
ptrender[yaml,dev] $ grep '^(strictyaml|ipython|flit)=' requirements.txt
flit==2.2.0 # via ptrender
ipython==7.12.0 # via ptrender
strictyaml==1.0.6 # via ptrender These are defined for the package via a flit-flavored [tool.flit.metadata.requires-extra]
dev = ["flit", "ipython"]
yaml = ["strictyaml"] And this becomes the following in the flit-generated legacy-compatible extras_require = \
{'dev': ['flit', 'ipython'], 'yaml': ['strictyaml']} |
@AndydeCleyre So yes, I'm sure, but I might have expressed what I meant in a confusing way. What I meant is that for I'll take this example:
Let's says you do Now with the
If I run Now that I think of it, we can test and check
If I'm right, the interesting part is this one: As a proof, using
We can see that So bottom line, it seems that even if all of the package are theorically "top-level dependencies" because they are directly listed in the requirements.txt, (Reminder that I hold the right to be wrong, that this was a mix of analysis, learning new things, and trying to put a demonstration together, and that I welcome anyone who knows better to challenge this 😄) |
something I do for this case is:
|
but really this is a bug in gdal - it shouldn't be inspecting the state of the virtualenv at install time |
Yup -- pip installs "bottom up" in the dependency tree -- installing the dependencies before dependent package, regardless of what is specified on the top level.
pip doesn't care about the "original source" of how it "discovered" a requirement to satisfy.
Yup. :) Relevant bit of code: https://github.com/pypa/pip/blob/9e884a46f632815826be51a55eb7a285b351f513/src/pip/_internal/resolution/legacy/resolver.py#L402 |
Given all this, I think we can close this, yes? To sum up:
|
I know this issue is closed but I want to make a use case if this is ever revisited.
|
I have a similar issue as @jagibson Ubuntu Bionic ships with python 3.6 and I want to install Numba.
Which should work, but pip tries to install numba first, which in turn installs numpy 1.21, which requires python3.7+, so the installation just fails. |
@hfingler try using the deadsnakes PPA to install a newer version of Python Also upgrade the version of pip in your virtual environment to one that supports requires-python before installing your requirements.txt |
@graingert thanks for the tips, but my specific use case is a little more complicated than that. I have a ubuntu debootstrap'd image that I chroot in to install a few things, like python packages. I ended up just doing this (copy-pasted from stackoverflow): |
deadsnakes ppa is designed to work safely with your system python version |
What's the problem this feature will solve?
Sometimes the order of installation of packages is important. But if you organise the order in your requirements.in, the output from pip-compile will be sorted by package name. This makes can cause problems later. My example is with numpy and gdal; in order to get certain bindings, gdal first checks to see if you have numpy installed, and if you do it will give you certain additional bindings.
---requirements.in---
Results in the file
---requirements.txt---
Now after
pip-sync
you'll get gdal installed first. Thenwill give you an error.
Describe the solution you'd like
Optionally keep the order of the packages in requirements.in the same as requirements.txt.
Alternative Solutions
My solution at the moment is to edit requirements.txt to change the order. But this breaks some of the nice automatic feature.
Additional context
The text was updated successfully, but these errors were encountered: