Closed hynek closed 6 years ago
Here we go
> /Users/hynek/.local/venvs/pipenv/lib/python3.6/site-packages/pipenv/patched/piptools/repositories/pypi.py(176)get_dependencies()
-> try:
(Pdb) p self.use_json
False
(Pdb) l
171 except TypeError:
172 json_raised = True
173 json_results = set()
174
175 legacy_raised = False
176 -> try:
177 legacy_results = self.get_legacy_dependencies(ireq)
178 except Exception:
179 legacy_raised = True
180 legacy_results = set()
181
(Pdb) n
> /Users/hynek/.local/venvs/pipenv/lib/python3.6/site-packages/pipenv/patched/piptools/repositories/pypi.py(177)get_dependencies()
-> legacy_results = self.get_legacy_dependencies(ireq)
(Pdb) n
TypeError: _prepare_file() got an unexpected keyword argument 'ignore_requires_python'
Don't do silent Pokemon catches Kenneth! ;)
I knew that was a bad idea — i blame logging
Quick zoom:
This is actually reminiscent of another bug another user is having. _prepare_file
absolutely takes ignore_requires_python
.
Hmmm:
(Pdb++) inspect.signature(reqset._prepare_file)
<Signature (finder, req_to_install, require_hashes=False, ignore_dependencies=False)>
Confirmed in the tar.gz from PyPI. So, it's not an upload issue.
(finder, req_to_install, require_hashes=False, ignore_dependencies=False, ignore_requires_python=False)
I'm gonna guess it’s some import problem and it uses pip.req.req_set.RequirementSet
from pip instead the vendored version…
We put our vendored version at the beginning of sys.modules in our __init__
but i'll change it to be on the safe side
no, everything it should be working as expected.
https://github.com/pypa/pipenv/blob/master/pipenv/__init__.py#L11
you have to invoke the function from a pipenv import, obviously (as the codebase does).
I don't think that exception's normally raised.
I’ve got some bad news:
(Pdb++) sys.path
['/Users/hynek/.local/venvs/pipenv/lib/python3.6/site-packages/pipenv/..', '/Users/hynek/.local/venvs/pipenv/lib/python3.6/site-packages/pipenv/patched', '/Users/hynek/.local/venvs/pipenv/lib/python3.6/site-packages/pipenv/vendor', '/Users/hynek/.local/venvs/pipenv/lib/python3.6/site-packages/pipenv/patched', '/Users/hynek/.local/venvs/pipenv/lib/python3.6/site-packages/pipenv/vendor', '/Users/hynek/.local/venvs/pipenv/bin', '/Users/hynek/.local/venvs/pipenv/lib/python3.6/site-packages/_pdbpp_path_hack', '/Users/hynek/.local/venvs/pipenv/lib/python36.zip', '/Users/hynek/.local/venvs/pipenv/lib/python3.6', '/Users/hynek/.local/venvs/pipenv/lib/python3.6/lib-dynload', '/Users/hynek/.pyenv/versions/3.6.4/lib/python3.6', '/Users/hynek/.local/venvs/pipenv/lib/python3.6/site-packages']
The first entry is site-packages of the venv.
omg, thank you
this explains so much
It probably also explains the wildly different behaviors we observed.
Cutting a release as soon as CI passes.
Thanks for your due-diligence on this one, @hynek. You've really helped a lot.
You also have earned a cookie: 🍪
👐
FYI, in https://github.com/pypa/pipenv/blob/a8b75f42cd3eaa56a406b75d75c3313bd772161c/pipenv/patched/piptools/repositories/pypi.py#L180 legacy_raised cannot ever be True.
Aware — it's there for later iteration.
the original logging mechanisms are back in place now, by not catching all exceptions:
Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
You can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
Could not find a version that matches aohweofihwaoeifhowef
Tried: (no version found at all)
Please check your version specifier and version number. See PEP440 for more information.
now that i've made these changes, i'm somehow reproducing your error in tests/ci.
You do? SEE I’M NOT CRAZY!
FWIW I knew there was a reason I made a local descendent of RequirementSet
when I was doing this and imported from .req_set! Can you bisect back to a specific change that caused this?
non deterministic
I love how you use your $200 font literally everywhere.
I got it for free, for the record :)
Yeah, rub it in. :P
okay, fixed it!
Commit???
i was doing something dumb
tests running now, assuming successful pass, will be released momentarily.
v11.3.2 releaed. Please test @hynek :)
$ pipenv lock
Locking [dev-packages] dependencies…
nged, best_matches = self._resolve_one_round()
File "/Users/hynek/.local/venvs/pipenv/lib/python3.6/site-packages/pipenv/../pipenv/patched/piptools/resolver.py", line 200, in _resolve_one_round
for dep in self._iter_dependencies(best_match):
File "/Users/hynek/.local/venvs/pipenv/lib/python3.6/site-packages/pipenv/../pipenv/patched/piptools/resolver.py", line 297, in _iter_dependencies
dependencies = self.repository.get_dependencies(ireq)
File "/Users/hynek/.local/venvs/pipenv/lib/python3.6/site-packages/pipenv/../pipenv/patched/piptools/repositories/pypi.py", line 171, in get_dependencies
legacy_results = self.get_legacy_dependencies(ireq)
File "/Users/hynek/.local/venvs/pipenv/lib/python3.6/site-packages/pipenv/../pipenv/patched/piptools/repositories/pypi.py", line 206, in get_legacy_dependencies
result = reqset._prepare_file(self.finder, ireq, ignore_requires_python=True)
File "/Users/hynek/.local/venvs/pipenv/lib/python3.6/site-packages/pipenv/../pipenv/patched/pip/req/req_set.py", line 699, in _prepare_file
self.requires_python = check_dist_requires_python(dist, absorb=False)
TypeError: check_dist_requires_python() got an unexpected keyword argument 'absorb'
Seems like you missed some import?
also:
$ pipenv-resolver 'autobahn[encryption,accelerate,asyncio,serialization]'
Traceback (most recent call last):
File "/Users/hynek/.local/bin/pipenv-resolver", line 11, in <module>
sys.exit(main())
File "/Users/hynek/.local/venvs/pipenv/lib/python3.6/site-packages/pipenv/resolver.py", line 54, in main
results = resolve(packages, pre=do_pre, sources=project.sources, verbose=is_verbose, clear=do_clear)
File "/Users/hynek/.local/venvs/pipenv/lib/python3.6/site-packages/pipenv/resolver.py", line 52, in resolve
return pipenv.utils.resolve_deps(packages, which, project=project, pre=pre, sources=sources, clear=clear, verbose=verbose)
File "/Users/hynek/.local/venvs/pipenv/lib/python3.6/site-packages/pipenv/utils.py", line 398, in resolve_deps
resolved_tree, resolver = actually_resolve_reps(deps, index_lookup, markers_lookup, project, sources, verbose, clear, pre)
File "/Users/hynek/.local/venvs/pipenv/lib/python3.6/site-packages/pipenv/utils.py", line 331, in actually_resolve_reps
resolved_tree.update(resolver.resolve(max_rounds=PIPENV_MAX_ROUNDS))
File "/Users/hynek/.local/venvs/pipenv/lib/python3.6/site-packages/pipenv/patched/piptools/resolver.py", line 102, in resolve
has_changed, best_matches = self._resolve_one_round()
File "/Users/hynek/.local/venvs/pipenv/lib/python3.6/site-packages/pipenv/patched/piptools/resolver.py", line 200, in _resolve_one_round
for dep in self._iter_dependencies(best_match):
File "/Users/hynek/.local/venvs/pipenv/lib/python3.6/site-packages/pipenv/patched/piptools/resolver.py", line 284, in _iter_dependencies
for dependency in self.repository.get_dependencies(ireq):
File "/Users/hynek/.local/venvs/pipenv/lib/python3.6/site-packages/pipenv/patched/piptools/repositories/pypi.py", line 171, in get_dependencies
legacy_results = self.get_legacy_dependencies(ireq)
File "/Users/hynek/.local/venvs/pipenv/lib/python3.6/site-packages/pipenv/patched/piptools/repositories/pypi.py", line 206, in get_legacy_dependencies
result = reqset._prepare_file(self.finder, ireq, ignore_requires_python=True)
File "/Users/hynek/.local/venvs/pipenv/lib/python3.6/site-packages/pipenv/patched/pip/req/req_set.py", line 699, in _prepare_file
self.requires_python = check_dist_requires_python(dist, absorb=False)
TypeError: check_dist_requires_python() got an unexpected keyword argument 'absorb'
Presumably that is also import related. It seems like the prescribed path modifications are not happening at runtime.
Likely because we need to set PYTHONPATH
as well
yes working on it
(Or unset it—do you have it set?)
Lol. What changed about it though?
making all of pip relative imports
just patching sys.path again
i need to take a break — @techalchemy feel free to dig into this.
k got 11.3.3 out — think it fixes this for good
will take a deeper look in the morning though, this is the "putting out the fire" release
Something is still broken. I could narrow it down to installing keyring
which will just silently exit with code 1.
Verbose output is more helpful:
It seems like it catches itself in an infinite loop flip-flopping the conditional marker.
I wonder if that’s related to the bug I keep complaining about but that I wasn’t able to reproduce where pipenv will randomly flip-flop markers on a lock.
Whoa wtf. @hynek can you pipenv-resolver keyring --debug --clear --verbose
? Is this into a clean environment? Did you explicitly pin keyring
? And does this only happen when you put it in dev-packages
?
i think that's for another issue :)
JFTR, I cannot reproduce it anymore either which makes me 99.9% confident it’s the same bug that haunts me by occasionally stripping markers from the lock files.
Sorry I don’t have the time for the full template dance, but I woke up to a broken pipenv update and could pinpoint it to:
pipenv install --dev -e .
pipenv lock
if the Pipfile contains -e .This is what I get with latest pipenv on lock:
This is what I get with latest pipenv on
pipenv install --dev -e .
: