<div class="gmail_quote">On Fri, Dec 7, 2012 at 3:47 PM, PJ Eby <span dir="ltr"><<a href="mailto:pje@telecommunity.com" target="_blank">pje@telecommunity.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In effect, a "conflicts" field actually *creates* conflicts and<br>
maintenance burdens where they did not previously exist, because even<br>
after the conflict no longer really existed, an automated tool would<br>
have prevented PyDispatch from being installed, or, per your<br>
suggestion above, unnecessarily *uninstalled* it after a user<br>
installed RuleDispatch.<br></blockquote><div><br>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.<br>
<br>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:<br>
1. Use virtual environments to keep the two projects isolated from each other<br>2. Use an installer that ignores Conflicts information (which will be all of them, since that's the status quo)<br>3. Make their case to the upstream project that the conflict has been resolved, and installing the two in parallel no longer causes issues<br>
<br></div></div>Cheers,<br>Nick.<br clear="all"><br>-- <br>Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>