Unable to lock from private PyPI #3244
Labels
Status: Needs More Information
This issue does not provide enough information to take further action.
Comments
|
Having the same error, but when doing: |
|
Can you do |
frostming
added
the
Status: Needs More Information
|
Oh, that is probably because you install |
|
Yes, sorry I found it right after I posted and deleted my comment |
|
I believe there is some subtlety here around private indexes -- if you remove pypi from the list of sources, you won't ever look in pypi during resolution. This was always intended to be the behavior and if there isn't a changelog entry for it that was a big oversight and is probably my fault. We don't assume you want to use pypi at all, so if you get rid of it we aren't going to check there. All of your dependencies need to be in the sources you provide us. If you want to include pypi in your resolution order, you need to include it in your pipfile below the private index you want to prioritize: Let me know if this solves your issue |
|
Here's the output of the |
|
@techalchemy thanks I've omitted some info for brevity's sake that I realize now is confusing. I actually have two |
No way, it turns out to work! |
|
The pipenv-resolver works, but I'm still getting the above stacktrace on |
|
I'm having the same problem without private sources. I created a new pipenv virtual environment, and started installing some packages: inflection, matplotlib, pandas, pendulum, jinja2, .. no problem. Until I did a Manual runs of
I'm using pipenv 2018.11.14-1 and never had any issues with previous versions (starting at 2018.7.1-2). Hope this bug report helps in getting the issue resolved. I'd be happy to provide more info when needed. |
|
Aha! After almost seven minutes, |
|
Seems like a caching issue in that case. I think there may still be a real issue here |
|
With this pipfile, I can't replicate the issue: Locking is working just fine for me against master so I'll need an example that reproduces teh issue against teh master branch otherwise I'm afraid there isn't much we can do. Try |
|
Yeah I totally get that this is a weird one. I'm hoping someone else out there can replicate it and shed some more light on it. I've tried the |
|
aha, setting So if it's timing out, perhaps a better error message could be printed to let the user know that's what is happening? |
|
What's super weird is we didn't change the timeouts at all... how long does it actually take to lock? |
|
For the whole time (PIPENV_TIMEOUT=3600 pipenv lock)
Locking [dev-packages] dependencies…
✔ Success!
Locking [packages] dependencies…
✔ Success!
Updated Pipfile.lock (82079d)!
real 3m27.111s
user 0m47.661s
sys 0m10.210sI notice in the stacktrace that |
|
I had this same traceback with a plain |
|
I’ll try bumping the timeout a bit for individual lock operations in this release. I think this might be impacting timeouts of subprocess runtimes in a new way |
|
Thanks for your patience and for the helpful debugging information— hopefully the changes are actually improving the UX overall |
|
Encountered the same issue, definitely a timeout (although, not clear at all what takes so long - is there a way to get a sense of where pipenv spends so much time locking the deps?): I was about to give up on pipenv while building my container, then I swapped it for the The failure needs to be caught and a better error message (maybe with the hint to tweak the This: is a good hint that there's a timeout there (especially as it happens after waiting forever) but then this throws everyone off the scent: |
techalchemy
added a commit
that referenced
this issue
Nov 26, 2018
- Fixes #3244 Signed-off-by: Dan Ryan <[email protected]>
|
For anyone who comes across this thread, the following can also result in the original error:
Resolution:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am currently unable to lock my Pipfile when using our private PyPI sources on
2018.11.14. This issue hadn't appeared on prior versions of pipenv. I suppose it's possible that our private PyPI sources are the problem, but I'm not sure what could be happening.This is an example
Pipfilethat causes the error:Running
pipenv installyields the following logs:Replacing the
[[source]]section with the default appears to resolve the issue, but then I'm unable to install private pips.$ pipenv --support
Pipenv version:
'2018.11.14'Pipenv location:
'/usr/local/lib/python3.7/site-packages/pipenv'Python location:
'/usr/local/bin/python'Python installations found:
3.7.1:/usr/local/bin/python3.7.1:/usr/local/bin/python3.7m3.5.3:/usr/bin/python3.53.5.3:/usr/bin/python3.5m2.7.13:/usr/bin/pythonPEP 508 Information:
System environment variables:
PATHHOSTNAMETERMLANGGPG_KEYPYTHON_VERSIONPYTHON_PIP_VERSIONHOMEPIP_DISABLE_PIP_VERSION_CHECKPYTHONDONTWRITEBYTECODEPIP_SHIMS_BASE_MODULEPIP_PYTHON_PATHPYTHONFINDER_IGNORE_UNSUPPORTEDPipenv–specific environment variables:
Debug–specific environment variables:
PATH:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binLANG:C.UTF-8Contents of
Pipfile('/Pipfile'):The text was updated successfully, but these errors were encountered: