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

@kaustavha kaustavha commented Jan 19, 2016

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

@xavfernandez xavfernandez commented Jan 19, 2016

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 Jan 20, 2016
…e specs, dont raise a double requirement given error
@kaustavha kaustavha force-pushed the kaustavha/fix/double-reqs branch from bb6eb0c to fbfa7fb Compare Jan 20, 2016
@kaustavha
Copy link
Contributor Author

@kaustavha kaustavha commented Jan 21, 2016

@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 issue 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
1 check passed
@xavfernandez
Copy link
Member

@xavfernandez xavfernandez commented Jan 25, 2016

Thanks :)

@zsalzbank
Copy link

@zsalzbank zsalzbank commented Feb 26, 2016

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 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

@kaustavha kaustavha commented Jul 11, 2016

@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

@piotr-dobrogost piotr-dobrogost commented Jul 15, 2016

What is someDep * supposed to mean?

@Brendenvski
Copy link

@Brendenvski Brendenvski commented Jul 20, 2016

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 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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants