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 😆). 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!

[ch3ck]

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

[patelamol]

I experienced this bug in all the latest version until 2018.11.26. So 2018.11.26 doesn’t have this issue.