Pipenv: Absolute paths for -e . in lock -r

[hynek]

Since 2018.6.25, pipenv install --dev -e . gets resolved to absolute paths when running pipenv lock --requirements --dev >dev-requirements.txt.

That has the downside, that that .txt is only usable by the person who locked the dependencies if you (like us and I’m sure many more) use Pipenv to manage your deps, but use standard .txt files to deploy/tox.

I’m sure you had good reasons to change this behavior but it would be great to have an option to get the old back.

[uranusjr]

I’m quite confident this is an oversight :) We make efforts to make sure the path is correct in Pipfile and Pipfile.lock, there’s little reason the same wouldn’t apply for requirements.txt.

[hynek]

Well it is “correct” in a sense – it’s just not portable. :)

[jkp]

This has changed in the latest release and doesn't just involve requirements.txt. If you feed pipenv lock or pipenv install --skip-lock a Pipfile from the previous version (which used a hash for the package name and relative paths), it will convert them to be keyed by the package name (nice) with absolute paths (not portable).

[mmarksnippety]

:-1:
Absolute paths are not portable :(
It is very bad changes. We use pipenv install -e . This behavior killing usage pipenv in our team project.
We are saddened by this change.

[uranusjr]

Thank you for the input. We are already investigating the issue, and will definitely fix this as soon as possible. Please do provide help if this is an urgent issue for you.

[pawelswiecki]

@mmarksnippety Having the same issue. Relative path should be supported and possibly be default.

[techalchemy]

We are aware of the issue, you don't need to comment and tell us it's a bad change. It's a bug, we are fixing it. Unless you have a new development please be patient or make a productive contribution.