(original) (raw)

If I'm installing both A \*and\* B, I want to know if \*either\* project doesn't support that configuration. The order in which they get installed should \*not\* have any impact on my finding out that I am using one of my dependencies in an unsupported way that may cause me unanticipated problems further down the line.

The author of A \*doesn't\* get to decide what happens to B, \*I\* do. They're merely providing a heads up that they believe there are problems when using their project in conjunction with B. My options will be:
\- use them both anyway (e.g. perhaps after doing some research, I may find out the conflict relates solely to a feature of B that I'm not using, so I simply update my project documentation to say "do not use feature X from project B, as it conflicts with dependency A")
\- choose to continue using A, find another solution for B
- choose to continue using B, find another solution for A

As a concrete example, there are projects out there that are known not to work with gevent's socket monkeypatching, but people don't know that until they try it and it blows up in their face.

I now agree that \*enforcing\* a conflicts field at install time in a Python installer doesn't make any sense, since the nature of Python means it will often be easy to sidestep any such issues once you're aware of their existence (e.g. by avoiding gevent's monkeypatching features and using threads to interact with the uncooperative synchronous library, or by splitting your application into multiple processes, some using gevent and others synchronous sockets). I also believe that \*any\* Conflicts declaration \*should\* be backed up with an explicit explanation and rationale for that conflict declaration in the project documentation.

Making it impossible to document runtime conflicts in metadata doesn't make those conflicts go away - it just means they will continue to be documented in an ad hoc manner on project web sites (if they get documented at all), making the job of package curation unnecessarily more difficult (since there is no standard way to document runtime conflicts). Adding a metadata field doesn't make sure such known conflicts \*will\* be documented, but it least makes it possible.

So, I still like the idea of including a Conflicts field, but think a few points should be made clear:
- the Conflicts field would be for documenting other distributions which have known issues working together in the same process and thus constitute an unsupported configuration
\- this field would be aimed at package \*users\*, rather than at installation tools (although it would still be good if they installation tools supported scanning a set of packages for known conflicts)
- any use of this field should be backed up with a more detailed explanation in the project documentation

Cheers,
Nick.