Confusing default behaviour of pipenv install 'name'

[januszm]

Issue description

It goes as far as to say that good software doesn't like side effects, or violating the "principle of least surprise". Unfortunately, I have the impression that this is what pipenv install does. It updates packages and changes the lock file where it shouldn't.

Expected result

pipenv install package_name should install the specified (or latest if unspecified) version of the package. E.g. pipenv install --dev yapf should:

1. add yapf = "*" to [dev-packages] in Pipfile
2. add it to the Pipfile.lock (with hash, current version and so on).
   But it should never touch other packages in Pipfile.lock unless they are direct dependencies of the newly installed package.

Actual result

pipenv install --dev yapf updates other packages (surprise !), it changes the lockfile where it shouldn't. pipenv update should be used to update packages and change the lockfile.

PS. See this great comment from @joaomcarlos #3150 (comment)

Also, there seems to be some inconsistency between the --help message and the actual behaviour of the pipenv install command without arguments. It seems that now install (no args) is equivalent to sync.

[matteius]

Can this be rechecked on pipenv==2022.8.19?

[matteius]

Sorry, I re-read the issue report, and I have to explain that pipenv install package_name has to relock -- this is part of the dependency resolution to be able install package_name and respect the other dependencies. Say that you have pinned to an old version of Django and package_name requires a new version of Django, nobody would want the side effect that pipenv install violates its own constraints, hence it has to go through the dependency resolution phase.

But it should never touch other packages in Pipfile.lock unless they are direct dependencies of the newly installed package.

This isn't true, what you are asking for is that the default behavior of install to be pipenv lock --keep-outdated but that is a flawed implementation and we should not prefer users to use that as the default. Furthermore, it seems you can already pass --keep-outdated to pipenv install, which sounds like what you want.

What you should be doing instead is actually picking proper specifiers for your project in the Pipfile such that you are not inconvenienced by re-locking when installing new packages, then you won't get bugged outcomes that are possible from using --keep-outdated in the first place.

Thanks for pointing out that other comment in that thread that has so many likes -- to me it represents a complete misunderstanding of what the pip resolver is capable of and the kind of guarantees it provides when you use it properly. Either way --keep-outdated or not, we invoke the pip resolver and in the case of --keep-outdated we only update some of the results which can lead to lock files that are not installable or will have unexpected compatibility outcomes.