pipenv install doesn't update Pipfile.lock if depedencies in editable local installations change

[josephong]

Hey there ya'll!

Apologies if this is intended behavior, if I'm making a simple mistake, or if there's another related issue. I tried searching but because terms like "install" and "install_requires" overlap it was hard to know for sure if an existing issue was already open.

---

Issue description

pipenv, version 2018.11.26

After an initial installation of an editable install of the local directory, pipenv install fails to update Pipfile.lock if setup.py is subsequently changed.

Code running in the repository fails to run because the changed dependencies are not installed.

Expected result

I expect pipenv install to generate a fairly consistent environment (within the bounds of abstract dependencies) regardless of whether it is run from an existing env or a new env.

Here, if setup.py had a new dependency added after a first install, I would expect pipenv install to update Pipfile.lock and to install the additional dependency.

Actual result

Pipfile.lock isn't updated when setup.py is changed, and thus the output of a fresh pipenv install is different from that of running pipenv install on an pre-existing setup.

While it's possible to always run pipenv lock --clear on every setup.py change, it makes the usage of the tool a little more awkward/prone to forgetfulness errors.

Steps to replicate

1. Use the following files:

Pipfile

[dev-packages]

[packages]
dependency_test = {editable = true,path = "."}

[requires]
python_version = "3.6"

setup.py

from setuptools import find_packages, setup

PACKAGE_NAME = 'dependency_test'

REQUIRED_PACKAGES = [
    'requests>=2.19.1',
]

setup(
    name=PACKAGE_NAME,
    version='0.1.0',
    packages=find_packages(),
    install_requires=REQUIRED_PACKAGES,
    package_data={ '': [] },
)

Run pipenv install. Note requests is installed.

1. Update files:

setup.py

from setuptools import find_packages, setup

PACKAGE_NAME = 'dependency_test'

REQUIRED_PACKAGES = [
    'requests>=2.19.1',
    'tqdm>=4.25.0',
]

setup(
    name=PACKAGE_NAME,
    version='0.1.0',
    packages=find_packages(),
    install_requires=REQUIRED_PACKAGES,
    package_data={ '': [] },
)

Run pipenv install. Note that tqdm is not installed.

[frostming]

pipenv install always installs from Pipfile.lock if it exists and will and relock only when the file is out of date, which means it doesn't match the content hash of your Pipfile.

Here the Pipfile.lock doesn't update bc your Pipfile is not changed. You need to pipenv lock first or pipenv update

[josephong]

This makes sense to me – the hash is simply computed on the contents of a Pipfile (I'm guessing this is store in the _meta field of Piplock.lock or something similar), which is super convenient.

There's no intention on making it so that a hash can somehow also be based on the dependencies of editable installs or the package version? I recognize doing this is not trivial, but this would make a workflow where all someone pretty much ever needs to run is pipenv install, which is a lot more simple for collaborative local development in package land which almost always relies on editable installs.

Does the same thing happen for editable VCS installations where a tag is not specified?

@kennethreitz, I see you use this model of having a Pipfile in a package with a setup.py for requests. For your project, do you also pipenv lock && pipenv install or pipenv update && pipenv install whenever you update your setup.py, versus just pipenv install for when you make changes in Pipfile? What is a best practice here that people can adopt?

If pipenv is philosophically against changing this, I'd be happy to update the documentation to add this as a "thing to watch out for" for pipenv + setup.py, since folks might be expecting that pipenv install handles everything like happens if you only have a Pipfile.

[frostming]

Just pipenv update will do the trick. pipenv update = pipenv lock && pipenv sync
That's what pipenv update does in this case. And it is reasonable to update when anything in your workspace is changed.

[josephong]

Ah ok, I see, thank you! I think am too used to npm land where one command does everything :), but when dependencies can be hand-specified in other files it makes sense to keep lock file updates from manually editing a file separate from the pipenv install which adds something to the Pipfile.