On Fri, Dec 7, 2012 at 8:33 PM, Nick Coghlan <ncogh...@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? _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com