editable dependency causes wrong versions to be installed #4078
Comments
|
Anything I can do to assist with triage? |
|
ping |
|
The solution to this (to avoid compatibility issues in the next release anyway) will be to set Currently pipenv allows VCS dependencies to resolve on the fly unless they are installed in Sorry for the issue! |
techalchemy
added
Category: Dependency Resolution
techalchemy
added
Priority: Medium
|
https://github.com/bottom-text-everywhere/test-python-project/blob/master/Dockerfile#L7 Adjusting from version "2018.11.26" to "2020.5.28" ended up installing the RIGHT versions of dependencies and the Pipfile.lock file has new sha256 entries. Is there any unit test or feature that should be added to ensure that constraints/contracts enumerated by the Pipfile are verified at the end of installing/syncing/locking dependencies? I can see this easily popping up again as people mix more flags into play ( note that adding PIPENV_RESOLVE_VCS=1 resulted in the same correct result with version 2020.5.28 so I'm not going to use it when we update our pipenv version ). My first rule when writing software is: "Don't lie to the user" I appreciate the feedback! Keep up the awesome work guys! |
|
This was definitely a bug in version 2018.11.26 Please let me know if you have any issue repeating it because I can 100% of the time and will modify my test for any env you need to use. I prefer linux ( and if I have to Mac ) - but I do all my real work in docker containers. |
|
From a user experience perspective I think we all can agree that it's definitely a bug: you're working with a dependency solver and it's not solving the dependency graph. From a tool maturity standpoint, it's a bunch of functionality that is honestly quite complicated and wasn't yet built as of the version you mentioned. From your perspective, you want to pin a version and have that take precedence no matter what -- for others, they want to install their (previously unresolveable) package and have it work. Because the nature of that problem means we don't know what that package will install along with it, it becomes a race to see what gets installed first -- your pinned package might win, (i.e. be installed last), but if it isn't, we would have no way of knowing anything ever conflicted with it as pipenv is not actually performing the installation. This is not impossible per se -- but again, the validation required was not something that we had developed. Hopefully that provides some insight about why things were the way they were -- far from perfect, for sure.
The issue is pretty well understood -- we really just were not resolving these at all in some cases because there was no tooling built around that use case. Over the last ~1 year we have built the tools to handle this a lot more robustly, which is why you can expect better / more thorough resolution now |
I actually have a different request and perspective. The Request:Please verify the end virtualenv package version contents against the set of constraints discovered when traversing a dependency tree as a lockfile is constructed/updated and possibly when installing from a lockfile's metadata view. Lets Get Technical:I understand the intricacies of resolving a tree of dependencies where each subsequent dependency can introduce another tree. If when traversing the tree of dependencies where results will be stored in a flat-way, a set of version constraints are incompatible and no resolution path is viable, then an error should be reported. I also know this is further complicated by the shear number of paths over time that pop up where constraints enumerate a minimum version but fail to set a maximum version. I am sure you have a technique for addressing these concerns and I trust they work. If I run Fail loud, fail proud, fail fast; fix and move on. 👍 The perspective:In my example, me enumerating the full set of dependencies and locking them to specific versions was a work around I chose to try. I was upgrading a project from pip to pipenv and wanted to make sure I kept all the same previously resolved dependency versions the same. Once I had a lockfile I would have gone back and made the versions in the Pipfile match the way they were declared in the legacy requirements.txt file. I was shocked to find that even when I attempted to lock the dependency to a specific version the resulting env DID NOT MATCH the explicit version I had stipulated. And that's my main issue I feel needs to be addressed in a more strict manner. This issue was a breach of expectations. This is especially bad when I see the lockfile says one version should be installed, but the reality is another version has made its way into the virtualenv that does not match the lockfile nor the Pipenv file. Pipenv can verify everything is khosher at least to the degree the various package authors and the root project importing packages stipulate in the Pipenv way, regardless of if there are legacy concerns from the way pip worked in the past. It was not a huge issue as we caught the subtly broken image had issues before it went live and a quick audit proved a version of a dependency was wrong and was causing the issue. I was just happy that we could explain some wonky behavior we've seen with Pipenv finally and offer a repeatable test back to everyone. I also can understand that this would seem pretty edgelord amongst the current community of users. Though I do have to wonder:
I would sleep much better at night knowing pipenv verifies that package versions are within the constraints discovered for the resolution path it chose. And I would sleep like a baby if I new for certain it honored the root project package constraints. In my opinion, this is behavior that needs to be looked at closer and prevented. I believed pipenv has two modalities:
The first would be used in cicd, the second in daily efforts as I import new things. Please let me know if my understanding is incorrect. This is how other tools like yarn, npm, gem, crystal shards work so I hope this holds true here. So far the latest version looks like it is miles ahead from the previous experience we had here! Thanks for your time and all the hard work! 😄 My only goal is to prevent a regression. Feel free to close this issue if you are certain a regression is no longer possible. |
|
Pipenv now feeds everything through the resolver -- I get that the previous behavior was not desirable, that's why we corrected it. All I'm saying is, given the situation at the time, the options were to have the previous behavior (sometimes, a VCS or file-based dependency would override something that was otherwise pinned or resolved) or to use pip which clobbers everything without regard for your environment. The previous approach handles most cases, operating under the assumption that this is surely better than just clobbering anything. Yes, the previous behavior couldn't fundamentally guarantee you a deterministic install if you didn't use editable dependencies.
This didn't work because pipenv didn't pass As a result, because this could happen in parallel, the VCS dependency will have its own dependencies installed at some arbitrary time -- and if done in serial, this happens as the last step. In old versions of pipenv, this is true even when using The latest versions of pipenv are able to resolve these dependencies and feed the constraints from the VCS dependencies into the initial constraint set of the resolver before resolution even begins. To illustrate the difference, lets take a sample [[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true
[dev-packages]
[packages]
colorama = "*"
requests = {git = "https://github.com/psf/requests.git", ref="5a1e738ea9c399c3f59977f2f98b083986d6037a"}
urllib3 = ">=1.25"
[requires]
python_version = "3.8"Pipenv 2018.11.26Pipenv 2020.6.2In the second case, /t/test2 pipenv lock --dev
[...snipped]
[pipenv.exceptions.ResolutionFailure]: Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
First try clearing your dependency cache with $ pipenv lock --clear, then try the original command again.
Alternatively, you can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
Hint: try $ pipenv lock --pre if it is a pre-release dependency.
ERROR: Could not find a version that matches urllib3<1.25,>=1.21.1,>=1.25 (from -r /tmp/pipenvlsx1jhhhrequirements/pipenv-81b4tigh-constraints.txt (line 5))
Tried: 0.3, 1.0, 1.0.1, 1.0.2, 1.1, 1.2, 1.2.1, 1.2.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.7.1, 1.8, 1.8.2, 1.8.3, 1.9, 1.9.1, 1.10, 1.10.1, 1.10.2, 1.10.3, 1.10.4, 1.11, 1.11, 1.12, 1.12, 1.13, 1.13, 1.13.1, 1.13.1, 1.14, 1.14, 1.15, 1.15, 1.15.1, 1.15.1, 1.16, 1.16, 1.17, 1.17, 1.18, 1.18, 1.18.1, 1.18.1, 1.19, 1.19, 1.19.1, 1.19.1, 1.20, 1.20, 1.21, 1.21, 1.21.1, 1.21.1, 1.22, 1.22, 1.23, 1.23, 1.24, 1.24, 1.24.1, 1.24.1, 1.24.2, 1.24.2, 1.24.3, 1.24.3, 1.25, 1.25, 1.25.1, 1.25.1, 1.25.2, 1.25.2, 1.25.3, 1.25.3, 1.25.4, 1.25.4, 1.25.5, 1.25.5, 1.25.6, 1.25.6, 1.25.7, 1.25.7, 1.25.8, 1.25.8, 1.25.9, 1.25.9
There are incompatible versions in the resolved dependencies:
urllib3<1.25,>=1.21.1 (from -r /tmp/pipenvlsx1jhhhrequirements/pipenv-81b4tigh-constraints.txt (line 5))
urllib3>=1.25 (from -r /tmp/pipenvlsx1jhhhrequirements/pipenv-81b4tigh-constraints.txt (line 6))This is expected because it's a fundamental shift in the design of how the resolver works. Does this clear things up? |
|
Absolutely, thank you for taking the time to go into such detail. It looks like this would effectively surface the concerns of unresolvable constraint sets to the user and fail rather than break any constraint contract/expectation set by the user on any level of the dependency tree. Glad to see that it is now possible to resolve all dependencies in the tree before installing them. Again, great work all! |
|
Because it is already fixed in 2020.6.2, I am closing it now. |
Issue description
An error is not reported at the end of a
pipenv synccommand if an installed dependency violates a constraint / does not match the version specified in the lockfile.An error is not reported at the end of creating a lockfile via
pipenv installif an installed dependency violates a constraint specified in the Pipenv file / newly created lockfile.Looks like an editable dependency is key to causing this issue.
May be related to #3296
Note that there appears to be a datarace involved as SOMETIMES when I run
pipenv installthe versions that are installed match the generated/established lockfile and SOMETIMES they do not!The test case I describe here will be able to repeat the issue consistently. It appears to happen whenever there is a dependency of an editable dependency that is loosely locked down ( > or >= or < or <= or * ) this rarely happens if at all when such a dependency is locked down exactly ( == )
Output from test:
Expected result
I expect installed dependency versions to not violate constraints specified in the Pipenv file and I expect dependencies that are installed when running
pipenv syncorpipenv installto match exactly the version specified in the lockfile - whether that lockfile be pre-existing or newly created.If this does not happen, I expect an error to be reported.
( In addition, if the lockfile exists and I run
pipenv syncI still expect the lockfile and Pipenv file to remain unchanged. Though there appears to be no issue around that combination of conditions I feel it should be enumerated. )Actual result
Versions of dependencies that violate the top-most Pipenv file are installed when running
pipenv install. Also they do not match the version stated in the newly created lockfile.Versions of dependencies that do not match the lockfile are installed when running
pipenv sync.No error is thrown.
Steps to replicate
Made a couple of minor tests that express the problem:
On a linux friendly system with make:
clone https://github.com/bottom-text-everywhere/test-python-project
cd test-python-project
install docker
make testView the README.md file in the project root for more details.
There are two tests: calling
pipenv syncand callingpipenv installwhich creates a lockfile.$ pipenv --support
Pipenv version:
'2018.11.26'Pipenv location:
'/usr/local/lib/python3.7/site-packages/pipenv'Python location:
'/usr/local/bin/python'Python installations found:
3.7.5:/usr/local/bin/python3.7.5:/usr/local/bin/python3.7m3.7.3:/usr/bin/python3.7m3.7.3:/usr/bin/python3.72.7.16:/usr/bin/python2PEP 508 Information:
System environment variables:
PIPENV_VENV_IN_PROJECTHOSTNAMEPYTHON_VERSIONDOCKER_SHELL_ACTIVEPWDHOMELANGGPG_KEYTERMSHLVLPYTHON_PIP_VERSIONPYTHON_GET_PIP_SHA256PYTHON_GET_PIP_URLPATH_PIP_DISABLE_PIP_VERSION_CHECKPYTHONDONTWRITEBYTECODEPIP_SHIMS_BASE_MODULEPIP_PYTHON_PATHPYTHONFINDER_IGNORE_UNSUPPORTEDPipenv–specific environment variables:
PIPENV_VENV_IN_PROJECT:1Debug–specific environment variables:
PATH:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binLANG:C.UTF-8PWD:/workspaceContents of
Pipfile('/workspace/Pipfile'):Contents of
Pipfile.lock('/workspace/Pipfile.lock'):{ "_meta": { "hash": { "sha256": "5a05b2be1247f8f5df396dbe9a557d43c34516cb9b9c0ae3a3c2eb4b9fbfdd12" }, "pipfile-spec": 6, "requires": { "python_version": "3.7" }, "sources": [ { "name": "pypi", "url": "https://pypi.org/simple", "verify_ssl": true } ] }, "default": { "amqp": { "hashes": [ "sha256:2dea4d16d073c902c3b89d9b96620fb6729ac0f7a923bbc777cb4ad827c0c61a", "sha256:e0ed0ce6b8ffe5690a2e856c7908dc557e0e605283d6885dd1361d79f2928908" ], "index": "pypi", "version": "==1.4.9" }, "anyjson": { "hashes": [ "sha256:37812d863c9ad3e35c0734c42e0bf0320ce8c3bed82cd20ad54cb34d158157ba" ], "index": "pypi", "version": "==0.3.3" }, "babel": { "hashes": [ "sha256:d8cb4c0e78148aee89560f9fe21587aa57739c975bb89ff66b1e842cc697428f", "sha256:fed07cbcdcb3de79b53a8220eebed21c93f8dbb3dbce1d9c6b1c4b09e8aecf2b" ], "index": "pypi", "version": "==2.2.0" }, "billiard": { "hashes": [ "sha256:204e75d390ef8f839c30a93b696bd842c3941916e15921745d05edc2a83868ab", "sha256:23cb71472712e96bff3e0d45763b7b8a99e5040385fffb96816028352c255682", "sha256:692a2a5a55ee39a42bcb7557930e2541da85df9ea81c6e24827f63b80cd39d0b", "sha256:82041dbaa62f7fde1464d7ab449978618a38b241b40c0d31dafabb36446635dc", "sha256:958fc9f8fd5cc9b936b2cb9d96f02aa5ec3613ba13ee7f089c77ff0bcc368fac", "sha256:c0cbe8d45ba8d8213ad68ef9a1881002a151569c9424d551634195a18c3a4160", "sha256:ccfe0419eb5e49f27ad35cf06e75360af903df6d576c66cb8073246d4e023e5c", "sha256:d4d2fed1a251ea58eed47b48db3778ebb92f5ff4407dc91869c6f41c3a9249d0" ], "index": "pypi", "version": "==3.3.0.23" }, "celery": { "hashes": [ "sha256:434b4e62308428b0e83fbcd1cebb8853beb230237b1b23484063fcf1ff610b6e", "sha256:bd6a21290c822ecf78947a7dbc8b2270d88a5fa08a7a2bfcd908bb3d5ed66b71" ], "index": "pypi", "version": "==3.1.19" }, "certifi": { "hashes": [ "sha256:046832c04d4e752f37383b628bc601a7ea7211496b4638f6514d0e5b9acc4939", "sha256:945e3ba63a0b9f577b1395204e13c3a231f9bc0223888be653286534e5873695" ], "index": "pypi", "version": "==2019.6.16" }, "chardet": { "hashes": [ "sha256:84ab92ed1c4d4f16916e05906b6b75a6c0fb5db821cc65e70cbd64a3e2a5eaae", "sha256:fc323ffcaeaed0e0a02bf4d117757b98aed530d9ed4531e3e15460124c106691" ], "index": "pypi", "version": "==3.0.4" }, "flower": { "editable": true, "git": "https://github.com/mher/flower", "ref": "f20f43c858df3c0a94e5e10015fcd7d52089e3f0" }, "idna": { "hashes": [ "sha256:c357b3f628cf53ae2c4c05627ecc484553142ca23264e593d327bcde5e9c3407", "sha256:ea8b7f6188e6fa117537c3df7da9fc686d485087abf6ac197f9c46432f7e4a3c" ], "index": "pypi", "version": "==2.8" }, "importlib-metadata": { "hashes": [ "sha256:b044f07694ef14a6683b097ba56bd081dbc7cdc7c7fe46011e499dfecc082f21", "sha256:e6ac600a142cf2db707b1998382cc7fc3b02befb7273876e01b8ad10b9652742" ], "index": "pypi", "version": "==1.1.0" }, "kombu": { "hashes": [ "sha256:7ceab743e3e974f3e5736082e8cc514c009e254e646d6167342e0e192aee81a6", "sha256:e064a00c66b4d1058cd2b0523fb8d98c82c18450244177b6c0f7913016642650" ], "index": "pypi", "version": "==3.0.37" }, "more-itertools": { "hashes": [ "sha256:b84b238cce0d9adad5ed87e745778d20a3f8487d0f0cb8b8a586816c7496458d", "sha256:c833ef592a0324bcc6a60e48440da07645063c453880c9477ceb22490aec1564" ], "index": "pypi", "version": "==8.0.2" }, "pytz": { "hashes": [ "sha256:3ede470d3d17ba3c07638dfa0d10452bc1b6e5ad326127a65ba77e6aaeb11bec", "sha256:8b6ce1c993909783bc96e0b4f34ea223bff7a4df2c90bdb9c4e0f1ac928689e3", "sha256:99266ef30a37e43932deec2b7ca73e83c8dbc3b9ff703ec73eca6b1dae6befea", "sha256:fbd26746772c24cb93c8b97cbdad5cb9e46c86bbdb1b9d8a743ee00e2fb1fc5d" ], "index": "pypi", "version": "==2015.7" }, "requests": { "hashes": [ "sha256:11e007a8a2aa0323f5a921e9e6a2d7e4e67d9877e85773fba9ba6419025cbeb4", "sha256:9cf5292fcd0f598c671cfc1e0d7d1a7f13bb8085e9a590f48c010551dc6c4b31" ], "index": "pypi", "version": "==2.22.0" }, "tornado": { "hashes": [ "sha256:e8b1207da67dbdceebfb291292b4ef1b547d6171525bec1b366853f923456a5f" ], "index": "pypi", "version": "==4.2" }, "urllib3": { "hashes": [ "sha256:b246607a25ac80bedac05c6f282e3cdaf3afb65420fd024ac94435cabe6e18d1", "sha256:dbe59173209418ae49d485b87d1681aefa36252ee85884c31346debd19463232" ], "index": "pypi", "version": "==1.25.3" }, "vine": { "hashes": [ "sha256:133ee6d7a9016f177ddeaf191c1f58421a1dcc6ee9a42c58b34bed40e1d2cd87", "sha256:ea4947cc56d1fd6f2095c8d543ee25dad966f78692528e68b4fada11ba3f98af" ], "index": "pypi", "version": "==1.3.0" }, "zipp": { "hashes": [ "sha256:3718b1cbcd963c7d4c5511a8240812904164b7f381b647143a89d3b98f9bcd8e", "sha256:f06903e9f1f43b12d371004b4ac7b06ab39a44adc747266928ae6debfa7b3335" ], "index": "pypi", "version": "==0.6.0" } }, "develop": {} }The text was updated successfully, but these errors were encountered: