Tarek Ziadé wrote:
So... that's the kind of thing I encountered with just a couple
dependencies, but in practice it was much worse because there were a lot
more than 3 libraries involved. I now think it is best to only use version
requirements to express known conflicts. For future versions of packages
you can't really know if they will cause conflicts until they are released.
Exactly, you can't control everything from your package unless you
work in an isolated environement like virtualenv or zc.buildout
provides, so I can't see any solution unless someone is taking care of
it at a higher level :(
maybe PyPI though, can automate this, when a package is uploaded, by
browsing all dependency and
finding relevant conflict ? PyPI "knows" all the packages out there.
At least display those conflicts somehow ? or warn about them.
Yes, keeping this version information separate from packages would help,
I think. If you find out more information about a conflict it shouldn't
require a new release -- new releases take a while to do, and have
cascading effects. This kind of metadata isn't so much about the
package, as about how the package relates to other packages. If we
could somewhat safely have collaborative conflict information that would
be nice, though there's different kinds of conflicts so it might be
infeasible. It's all too common for a person to just poke around with
version stuff until something works, but in a way that is only accurate
for the context of their application, and if they submit that
information upstream they could easily break other people's setups
unnecessarily.
--
Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
