Allow "double requirements" if versions don't conflict
vbabiy opened this issue · 15 comments
I'd like to be able to compose a requirements file that uses the -r option to install several other packages by their own requirements files.
But in this use scenario, it's possible - even likely - that these separate packages may have overlapping requirements.
This works fine when installing each of them with a separate pip command, as long as you don't hit a version conflict; but when using one master requirements file that includes the others, you'd get the "Double requirement given" error.
I'd like to propose that it should not be an error unless there are version conflicts.
That may be tricky, as it means computing the union of the allowed versions, and pkg_resources confuses me so I'm not sure if there's a right way to do it.
- Bitbucket: https://bitbucket.org/ianb/pip/issue/196
- Originally Reported By:
- Originally Created At: 2010-12-20 22:51:49
My usecase is to have hierarchical requirement files, i.e. "running.txt" and "testing.txt" where "running" would only contain the bare minimum to make it run, i.e. "django>=1.3" and "testing" would need "django>=1.4" because some parts in the testing process use a newer API which is only available in the more recent version.
I'd like to be able to put "django>1.3" in my "running.txt" and then "-r running.txt django>=1.4" in my testing.txt
I have the same use case as muelli.
would be nice to have this feature.
+1
+1
+1
+1
+1
+1
+2, Approved :)
btw, I've started on this. will try to get a PR posted in a few days. involves some refactor that's needed to make things clearer about our dependency resolution.
I admit to not reading this issue correctly before. I'm closing this as a dupe to #988, which is our main issue for adding a proper resolver to pip. I just updated the description to cover resolving top-level requirements.
if anyone adding +1's here are actually concerned about literal duplicates across multiple requirement files, see #993. that is actually the problem I mentioned above that I was starting on.
See issue #1795
@qwcode
I don't think it's a duplicate of issue #988 as here the aim is to just "merge" all conditions of the same top-level package and it seems it's orthogonal to general problem of dependency management which is the subject of issue #988. If you agree this should be reopened and taken into consideration when discussing Requirements 2.0 in issue #1795
@piotr-dobrogost : I only closed this as a dupe after I updated the description of #988 to cover the problem of consolidating multiple top-level requirements for a project. so in a very literal sense, it is a dupe now. consolidating multiple top-level requirements seems similar to consolidating multiple in the dependency tree. I want #988 ticket to hold all the big fundamental changes to our resolver logic, which will likely get fixed at one time together.