[Python-Dev] Keyword meanings [was: Accept just PEP-0426] (original) (raw)
PJ Eby pje at telecommunity.com
Sat Dec 8 07:46:51 CET 2012
- Previous message: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]
- Next message: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, Dec 7, 2012 at 8:33 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
That's not what a Conflicts field is for. It's to allow a project to say they don't support installing in parallel with another package.
If that's the actual intended use case, the PEP needs some revision. In particular, if there's a behavioral recommendation for installer tools, it should be to avoid installing the project that declares the conflict, rather than the one that is the object of that declaration. ;-)
In any case, as I said before, I don't have an issue with the fields all being declared as being for informational purposes only. My issue is only with recommendations for automated tool behavior that permit one project's author to exercise authority over another project's installation. If the fields are defined in such a way that an author can only shoot themselves in the foot with a bad declaration, that's fine by me.
So if package A includes a "Conflicts: B" declaration, I recommend the following:
- An attempt to install A with B already present refuses to install A without a warning and confirmation
- An attempt to install B informs the user of the conflict, and optionally offers to uninstall A
In this way, any collateral damage to B is avoided, while still making the intended "lack of support" declaration clear.
How does that sound?
- Previous message: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]
- Next message: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]