<div><span style="color: rgb(160, 160, 168); ">On Friday, December 7, 2012 at 8:33 PM, Nick Coghlan wrote:</span></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
                    <span><div><div><div><div>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></div></div></div></div></span></blockquote><div>4. Use the eventual --force flag that any installer that supported conflicts is likely to include ;) </div><div><br>
                </div>