Warn if cli packages with the same name are installed
See original GitHub issueWhat’s the problem this feature will solve?
When installing two packages which register the same name for their CLI one of them gets overwritten. This introduces nondeterministic behavior which makes debugging more complex (See https://github.com/pypa/pip/issues/10861) Also, silently ignoring conflicts makes it harder for beginners (and experts) to spot them, e.g. take a lengthy list of dependencies and add a forked package (which has the same CLI command). Now one of them gets overwritten by the other without the user noticing it.
Describe the solution you’d like
If pip installs packages which use the same cli name it should warn the user that the packages are conflicting.
E.g.:
pip install papermill papermill-nb-runner
Collecting papermill!=3.0.5,>=2.0.2
Downloading papermill-3.0.7-py3-none-any.whl (98 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 98.0/98.0 KB 34.5 MB/s eta 0:00:00
...
Building wheels for collected packages: papermill-nb-runner
Building wheel for papermill-nb-runner (pyproject.toml): started
Building wheel for papermill-nb-runner (pyproject.toml): finished with status 'done'
Successfully built papermill-nb-runner
Installing collected packages: papermill, papermill-nb-runner
Successfully installed papermill-2.3.4 papermill-nb-runner-1.1.16
WARNING: Packages papermill and papermill-nb-runner are conflicting because they both registered the same cli name papermill.
Alternative Solutions
Ignore it and make it more difficult to find the underlying issue.
Additional context
https://github.com/pypa/pip/issues/4625 kind of wants to achieve the same but for all files. This issue should solely be about overwriting CLI package, because as discussed in the other issue it is inherently more complex to keep track of all files.
Code of Conduct
- I agree to follow the PSF Code of Conduct.
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (4 by maintainers)
Top GitHub Comments
I don’t think it’s going to be easier to implement this for a subset of the problem, as you’re hoping it would be – the implementation work for this would be roughly the same amount of work as implementing a solution for #4625, except using
entry_points.txt
as the source of inputs rather thanRECORD
.Yea, I’m gonna go ahead and consolidate this into #4625. While I agree that it is not-great that this stuff is taking so long, I don’t think this scope reduction is any easier to implement than the main logic needed that works for all files in general.
If someone really wants to work toward solving this, please see #4625.