Skip to content
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

fix(pip/req/req_set): Dont err on double reqs of the same spec #3372

Merged
merged 1 commit into from
Jan 25, 2016

Conversation

kaustavha
Copy link
Contributor

If double requirements exist with the same specs, dont raise a double requirement given error.

My reasoning is that if the user has the same version specified in more than one place this is an unnecessary level of hand holding and this error prevents people from writing more modular requirements.txts more than it prevents bugs.
If separate versions exist multiple times it makes sense to error out/ use a dependency resolver as discussed in #988 .

Fixes #993.

This does not affect #2367.
This is not related to #1658. I've noticed that if two git+... links are given with different egg names this code block doesn't affect them and it will happily install them even without the req.specs check. Checked on py 3.5.1 and 2.7.10.

Review on Reviewable

@xavfernandez
Copy link
Member

Seems ok, a test would be nice :)

@kaustavha kaustavha force-pushed the kaustavha/fix/double-reqs branch 2 times, most recently from 362f19f to bb6eb0c Compare January 20, 2016 04:51
…e specs, dont raise a double requirement given error
@kaustavha
Copy link
Contributor Author

@xavfernandez I have complied with your demands; merge away! Or make more demands of this pr and I will most likely comply

xavfernandez added a commit that referenced this pull request Jan 25, 2016
fix(pip/req/req_set): Dont err on double reqs of the same spec
@xavfernandez xavfernandez merged commit 24dc9b6 into pypa:develop Jan 25, 2016
@xavfernandez
Copy link
Member

Thanks :)

@zsalzbank
Copy link

Any word on when this will make it into an official release?

@xavfernandez xavfernandez added this to the 8.1 milestone Feb 28, 2016
@nikolay
Copy link

nikolay commented Jul 7, 2016

@kaustavha This still doesn't work for me. I have a requirements.txt file and also a requirements-common.txt file that doesn't have any versions specific and is included into requirements.txt via the -r command. I also have a requirements.txt.lock file, which is the frozen versions. Unfortunately, for whatever reason, the frozen requirements still has -r requirements-common.txt in it and thus it finds the same package without a version and also with a specific version, considers those different, and errors out. I'm using the latest version of pip, i.e. 8.1.2 as of this moment.

@kaustavha
Copy link
Contributor Author

@nikolay Sorry for the late reply.
tl;dr: Try just adding the version used in reqs.txt to reqs-common.txt.

If I am understanding you correctly, youre trying to do something slightly different than what I wrote here. Take a look at the test case in the pr.

So case 1:
req.txt

someDep 0.0.1
-r req-common.txt

req-common.txt

someDep *

In this case, pip cannot safely decide which version to pull.
What if the head has new problems? What if the programmer actually wants to be lazy everywhere and use * but the 0.0.1 came from some template code he copied and that version is now deprecated?

Now case 2:

req.txt

someDep 0.0.1
-r req-common.txt

req-common.txt

someDep 0.0.1

In this case, the code in this PR will check that both of the versions match and are consistent. Pip doesn't need to do any guessing, we've used the same version throughout. So instead of complaining and saying the requirement was specified twice it carries onto the next step.

Furthermore you can take a look at how deps are set up on this project.
https://github.com/rackerlabs/mimic/tree/master/requirements
iirc I made this PR stemming from errors building mimic and conversations with its author.

@piotr-dobrogost
Copy link

What is someDep * supposed to mean?

@Brendenvski
Copy link

its just an example of a dependency, so for example flask 0.2.2 would be a example

@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jun 3, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants