Conditional dependencies/markers are ignored when locking #1303
Comments
|
What version of Python did you install pipenv with? |
|
We’re doing a lot to attempt to support this — and it works well in most scenarios. Looks like you found a good corner case, potentially. |
|
looks like a depenedency resolution issue to me, and I dug into it a bit and mock actually doesn't include this information in its |
|
so would this be a path issue? we might be able to patch, if so. otherwise, this might be a wontfix |
3.6.3 but I’ve re-checked with 3.6.4 and it’s the same behaviour. |
|
OK another example that doesn’t use pbr: It has multiple markers: If you look into the Pipfile.lock, there is neither ipaddress nor enum34. Also as a side-note, the |
|
I’ve put significant effort into preserving these, but it’s difficult at best — packages all communicate this information differently. Do you get the same error when doing |
|
The reproducible problem (sorry for bringing up the PyPy thing; I will open a new issue one day) only can happen on |
|
After consulting my own blog post: yes this kind of syntax is kind of deprecated in favour of PEP 508 however it’s still very common because it was the only thing that worked until setuptools 36.2. |
|
Right but it won’t get parsed in a resolution graph until the package is installed afaik |
|
nothing we can do here at this time, i believe |
|
we typically do handle this case properly |
|
Maybe you should document it somewhere though? The behavior is subtly wrong and I just ran into it with another package. I think I’ll do a PyCon lightning talk about PEP 508 to get people move on. :| |
|
@ncoghlan that's right:
Pip-tools handles parsing by using a So far based on the call graph I can identify the following pieces that need to be fooled:
If at any point those resolve to the wrong interpreter (i.e. the host interpreter), resolution runs the risk of failing. So now I'm wondering if we shouldn't just 'install' a resolver script into the virtualenv and run it in that context and just dump the output to the host interpreter via a subprocess or something. |
|
Aye, while I think being able to generate the lock file without creating the venv first is a nice design goal, experience has shown us that doing so is currently too fragile to rely on (at least for now). |
|
As of v11, lock file generation resolves the dependencies using the venv Python, so the generated lock file should be independent of the host Python version now (it will still depend on the version of Python in the virtual environment). |
|
Yes, I can confirm it’s fixed now. Great work! |
|
p.s. that wasn't easy :) |
While installing packages that have conditions or markers on them (like “CFFI not on PyPy” for cryptography, or “funcsigs on Python before 3.3” on mock), those conditions are ignored.
I suspect this has something to do with another bug I keep running into but which I was not able to trigger reproducibly: sometimes after a
pipenv updatemy Pipfile.lock (and on pipenv lock --requirements the requirements.txt) gets markers added and after another pipenv update they get removed.Describe your environment
$ python -V: for Pipenv Python 3.6.3$ pipenv --version: 9.0.1 and latest master as of 2018-01-15Expected result
Conditions are respected.
Actual result
Conditions are ignored.
Steps to replicate
The easiest way to test this: go to an empty directory and type
pipenv install --two mock:As you can see,
funcsigsgets installed (“Successfully installed funcsigs-1.0.2 mock-2.0.0 pbr-3.1.1 six-1.11.0”).However it’s not present in Pipfile.lock:
{ "_meta": { "hash": { "sha256": "e3db12f7fd14f8b6216c97b58fcf0f9927bb85cfb3c4aa4b7b6a8bcf79a69885" }, "host-environment-markers": { "implementation_name": "cpython", "implementation_version": "0", "os_name": "posix", "platform_machine": "x86_64", "platform_python_implementation": "CPython", "platform_release": "17.3.0", "platform_system": "Darwin", "platform_version": "Darwin Kernel Version 17.3.0: Thu Nov 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64", "python_full_version": "2.7.14", "python_version": "2.7", "sys_platform": "darwin" }, "pipfile-spec": 6, "requires": { "python_version": "2.7" }, "sources": [ { "name": "pypi", "url": "https://pypi.python.org/simple", "verify_ssl": true } ] }, "default": { "mock": { "hashes": [], "version": "==2.0.0" }, "pbr": { "hashes": [], "version": "==3.1.1" }, "six": { "hashes": [], "version": "==1.11.0" } }, "develop": {} }That means:
pipenv update, it's gonna be gone in development.Curiously,
pipenv graphknows it should depend on funcsigs just fine and seems flabbergasted (?) by its absence:The text was updated successfully, but these errors were encountered: