-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dependency erroneously being marked local and editable in Pipfile.lock #4686
Comments
@jillianrosile Other than the issue of having to do the editable install twice because the first time it gets a Text File Busy error, I find that I do not get the same bug as you describe using latest version
EDIT: Actually the initial error had to do with my shared VM filesystem, so I will try this again now. |
@jillianrosile I just tried it out with
|
Issue description
I believe this is very similar to this closed issue but due to a
.serverless/requirements
directory for serverless rather than thevenv
directory in that issue. It appears to be an issue with any subdirectory that contains.egg-info
folders, but I'm providing the steps to reproduce for the serverless-specific example.The last external package listed in the default section of
Pipfile.lock
is being marked as local and editable when an editable self-dependency exists. This happens when runningpipenv lock
after running a serverless command that creates the.serverless/requirements
directory.I'm running pipenv version 2020.11.15.
Expected result
Last external package is provided from pypi.
Actual result
Last external package is marked editable and local, example:
Steps to replicate
Pipfile:
setup.cfg:
setup.py:
You'll need a
src
folder with__init__.py
, too.pipenv lock
runs as expected at this point with no bug when there is no.serverless/requirements
directory.Add a basic
serverless.yml
file to the project root, e.g.Then run
sls plugin install -n serverless-python-requirements
and thensls package
. This command will fail with the example setup, which doesn't matter, this bug will still be triggered.Run
pipenv lock
again.Diff:
The output of
pipenv --support
contained some things I'm not comfortable posting publicly related to my setup / environment vars, but if there are any snippets of it that aren't already included above that you need to reproduce this, please let me know and I can provide those.The text was updated successfully, but these errors were encountered: