pipenv: Fatal dependency resolution issue with editable dependencies
Checkout the code here and run test.sh with the latest version of pipenv to repro. Dependencies fail to resolve. If you revert to 2018.5.18 it works.
Additional info: moving the same sub-dependencies into the Pipfile directly also allows pipenv to resolve things properly (see the previous commit in the tree).
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 22 (6 by maintainers)
Commits related to this issue
- Add a test-case to demonstrate issue #2446 — committed to jkp/pipenv by deleted user 6 years ago
- Update requirementslib and re-patch piptools - Fix attempted hashing of `ssh://` urls - Fix URL parsing and conversions of `git` and `git+ssh` style vcs urls - Fixes #2653 - Fixes #2446 Signed-off-b... — committed to pypa/pipenv by techalchemy 6 years ago
- Update requirementslib and re-patch piptools - Fix attempted hashing of `ssh://` urls - Fix URL parsing and conversions of `git` and `git+ssh` style vcs urls - Fixes #2653 - Fixes #2446 - Update lock... — committed to pypa/pipenv by techalchemy 6 years ago
Hi - I downloaded and tried the latest release and this still seems to be a live issue. Can I help to move it forward in any way?
ssh://totally works with GitHub. The problem is that we are using the wrong format; it should bessh://git@github.com/private/repo.gitinstead.The problem likely lies into how requirementslib converts the URL before passing it into Git. We need to convert the
git@host:username/repo.gitformat intossh://git@host/username/repo.gitso we can correctly parse it withurllib.parseto get relevent URL information. I hope this helps you tracking down the problemthis issue still exists in version
2018.11.26@techalchemy This issue still persists with the current version 51cbc2e2f76a7c60f879a608fd96e95faca35f2e. It can be reproduced using @jkp’s example code that he linked to in the bug description.
It would be great if you could re-open this issue.
The
ssh://issue. I just saw that you have a test case in here — I haven’t looked at that yet but I’ll reopen now and take a look in a bit@techalchemy I’d love to keep this discussion focused on the bug report. I don’t know whether there is a history with previous bug reports that were filed in a non-constructive way, and if so, I really understand your pain. It is clear that everyone on this project is a volunteer, and you are perfectly right, people coming to this issue tracker shouldn’t just complain about things being broken.
At the same time, there are various ways to commit to a project. Making a pull request with a working solution to a problem is definitely the strongest way to commit, but the barrier of entry for outsiders for a significantly complicated project such as pipenv is very high. Another way to contribute is to provide a simple test case to narrow down the problem, which the author of this bug, @jkp, has done.
You may find his
test.shscript unnecessary; I personally very much enjoyed it - I used his example code to verify that the bug can be reproduced on my machine as well, and then commented in this thread to confirm that I can reproduce it. I have seen enough cases where a reported bug could not be reproduced on a different machine because of one person’s weird local machine configuration that I’ve come to value independent verifications of a bug a lot.If all of this sounds reasonable to you, I’d be very grateful if you reopened the ticket. Please don’t hesitate to ask for further information or other test cases if it helps in narrowing down the issue - I’m hopeful that this way, we can split the workload in debugging this, and ultimately help on improving what is already a fantastic package manager for Python.