[Python-Dev] Keyword meanings [was: Accept just PEP-0426] (original) (raw)
PJ Eby pje at telecommunity.com
Sat Dec 8 21🔞15 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 Sat, Dec 8, 2012 at 5:06 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
On Sat, Dec 8, 2012 at 4:46 PM, PJ Eby <pje at telecommunity.com> wrote:
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? No, that's not the way it works. A conflict is always symmetric, no matter who declares it.
But that precisely contradicts what you said in your previous email:
It's to allow a project to say they don't support installing in parallel with another package.
Just because A doesn't support being installed next to B, doesn't mean B doesn't support being installed next to A. B might work just fine with A installed, and even be explicitly supported by the author of B. Why should the author of A get to decide what happens to B? Just because I trust A about A, doesn't mean I should have to trust them about B.
Look, I really don't care about the individual fields' definitions that much. I care about only one thing: A shouldn't get to (de facto) dictate what happens to B. If you really want the behavior to be symmetrical, then it should only be symmetrical if both A and B agree they are in conflict. (i.e., both refer to the other in their conflict fields). Otherwise, it should only be a warning.
There are tons of other things that I could argue here about the positions you've laid out. But all I really care about is that we not define fields in such a way as to permit or encourage inter-package warfare -- intentional or not. Solutions acceptable to me include (in no particular order):
- Make declarations affect only the declarer (as with Obsoleted-By)
- Make declarations only warn users, not block installation or result in uninstallation
- Have no automated action at all, and document them as intended for downstream repackagers only
- Toss the field entirely
- Make the field include a context (e.g. a distro name), so that only tools explicitly told you're operating in that context pay attention
- Use the new metadata extension vocabularies to define hints for specific downstream packaging tools and systems
- Replace "conflicts" with a specification of resources actually used by the project, so that such conflicts can be automatically detected without needing to target a specific project
And there are probably others I haven't thought of yet. If you can be clearer about what it is you want from the Conflicts field other than just wanting it to stay as is (or perhaps why you would like to have the Python infrastructure side with project A over project B, irrespective of which project is A and which one is B), then perhaps I can come up with others.
- 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 ]