Pipenv: Last default dependency being marked as local and editable
Checked out diagnose documentation for common issues. I outlined my (possibly flawed) workflow in the steps to reproduce below. I've been fussing around with this for a couple weeks blaming myself, and would love for this to be a me-bug.
Issue description
Last external package listed in the default section of Pipfile.lock is incorrectly being marked as local and editable
Expected result
Last external package listed is still provided from pypi
Actual result
My Pipfile.lock get this diff included in it, which breaks CI and other users for obvious reasons:
"version": "==1.25.10"
},
"wrapt": {
- "hashes": [
- "sha256:b62ffa81fb85f4332a4f609cab4ac40709470da05643a082ec1eb88e6d9b97d7"
- ],
- "version": "==1.12.1"
+ "editable": true,
+ "path": "."
}
},
"develop": {
Steps to replicate
[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true
[dev-packages]
flake8 = "3.8.3"
pytest = "5.4.3"
pytest-cov = "2.10.0"
termcolor = "1.1.0"
[packages]
mycli = {editable = true, path = "."}
[requires]
python_version = "3.7"
(mycli has a setup.py to facilitate creating an entrypoint for python click and defines non-dev dependencies)
The project is a CLI utility and we clone the repository and install via:
PIPENV_IGNORE_VIRTUALENVS=1 PIPENV_VENV_IN_PROJECT=1 pipenv install --deploy
As a developer adding a new dependency, I edit the setup.py and run:
pipenv lock
This generates a Pipfile.lock file that does include my new dependency, but also a malformed last default dependency (I've had the issue with multiple packages that are near the end of the alphabet in that position, specifically wrapt and zipp)
I am able to workaround the issue and generate a correct Pipfile.lock by:
rm -rf Pipfile.lock .venv
and
pipenv lock
I am purposefully omitting the pipenv --support output because the application I'm working on is proprietary and I worry about leaking details of our environment (or our security team yelling at me :laughing:). If there are specific snippets i can scrub and provide I would be glad to, just didn't want to scrub the whole thing up front.
Thank you for reading and again, hope I'm just being dumb.
Thanks!
gregflynn
All 9 comments
@patelamol and I can reproduce this with pipenv 2020.08.13.
jmehnle
on 1 Oct 2020
I experienced this bug in all the latest version until 2018.11.26. So 2018.11.26 doesn't have this issue.
patelamol
on 2 Oct 2020
As @jmehnle and @patelamol commented, I've been experiencing a similar issue with some of my packages in this case
"zipp": {
"editable": true,
"path": "."
},
My solution was to manually edit the pipfile lock, which is unsafe/unhealthy to the latest version
"zipp": {
"hashes": [
"sha256:43f4fa8d8bb313e65d8323a3952ef8756bf40f9a5c3ea7334be23ee4ec8278b6",
"sha256:b52f22895f4cfce194bc8172f3819ee8de7540aa6d873535a8668b730b8b411f"
],
"version": "==3.2.0"
}
I wonder if there's a pipenv update coming out soon with this bugfix
ch3ck
on 9 Oct 2020
@gregflynn @patelamol So does this issue exist on the master branch? I can't reproduce with the given steps
frostming
on 27 Oct 2020
@gregflynn @patelamol So does this issue exist on the master branch? I can't reproduce with the given steps
Surely! I have not run pipenv from github before and didn't see instructions in the README so I'll be verbose about the steps:
- git cloned down
pyenv virtualenv 3.7.9 pipenv&&pyenv local pipenv&&pip install -e .- verification:
```
$ pipenv --version
pipenv, version 2020.8.13
$ ~/.pyenv/versions/pipenv/bin/pipenv --version
pipenv, version 2020.8.13.dev0
```
- made a fresh venv with 2020.8.13
- added
stockquotes == 2.0.0to my setup.py - ran
~/.pyenv/versions/pipenv/bin/pipenv lock - No dice, seeing the error with
"wrapt": {
- "hashes": [
- "sha256:b62ffa81fb85f4332a4f609cab4ac40709470da05643a082ec1eb88e6d9b97d7"
- ],
- "version": "==1.12.1"
+ "editable": true,
+ "path": "."
}
},
@frostming thank you for the suggestion and taking a look, happy to do more testing or correct this test if I've gone astray.
gregflynn
on 27 Oct 2020
@gregflynn
- made a fresh venv with 2020.8.13
Is this step critical to reproduce the bug? I create with master Pipenv and can't reproduce. A docker image would be of great help if possible
frostming
on 28 Oct 2020
@gregflynn
- made a fresh venv with 2020.8.13
Is this step critical to reproduce the bug? I create with master Pipenv and can't reproduce. A docker image would be of great help if possible
Good eye but I made the following changes and was still able to reproduce with latest master version. For step 4 I updated my install script:
-PIPENV_IGNORE_VIRTUALENVS=1 PIPENV_VENV_IN_PROJECT=1 pipenv install --deploy
+PIPENV_IGNORE_VIRTUALENVS=1 PIPENV_VENV_IN_PROJECT=1 $HOME/.pyenv/versions/pipenv/bin/pipenv install --deploy
and still got:
"wrapt": {
- "hashes": [
- "sha256:b62ffa81fb85f4332a4f609cab4ac40709470da05643a082ec1eb88e6d9b97d7"
- ],
- "version": "==1.12.1"
+ "editable": true,
+ "path": "."
}
},
Happy to try more things! Thanks
gregflynn
on 28 Oct 2020
Oh, I managed to reproduce it! I didn't notice the critical factor is VENV_IN_PROJECT.
frostming
on 29 Oct 2020
Oh, I managed to reproduce it! I didn't notice the critical factor is VENV_IN_PROJECT.
:raised_hands: great news! sorry I neglected to give you a Dockerfile, missed that note in my first read
gregflynn
on 29 Oct 2020
Related issues
bgjelstrup
·
3Comments
johnjiang
·
3Comments
randName
·
3Comments
jeyraof
·
3Comments
leileigong
·
3Comments
Most helpful comment
As @jmehnle and @patelamol commented, I've been experiencing a similar issue with some of my packages in this case
My solution was to manually edit the pipfile lock, which is unsafe/unhealthy to the latest version
I wonder if there's a pipenv update coming out soon with this bugfix