On Friday, December 7, 2012 at 8:33 PM, Nick Coghlan 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. It doesn't > matter why it's unsupported, it's making a conflict perceived by the project > explicit in their metadata. > > Such a field is designed to convey information to users about *supported* > configurations, regardless of whether or not they happen to work for a given > use case. If a user believes a declared conflict is in error, and having the > two installed in parallel is important to them, they can: > 1. Use virtual environments to keep the two projects isolated from each other > 2. Use an installer that ignores Conflicts information (which will be all of > them, since that's the status quo) > 3. Make their case to the upstream project that the conflict has been > resolved, and installing the two in parallel no longer causes issues 4. Use the eventual --force flag that any installer that supported conflicts is likely to include ;)
_______________________________________________ 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
