Chris Withers wrote:
Tarek Ziadé wrote:
Tarek Ziade wrote:
For KGS I agree that this is a big work, but there's the need to
work at a
higher level that in your package
Why? You really need to explain to me why the dependency information
in each
of the packages isn't enough?
Because you can keep up with the dependencies changes, removed, or
introduced
by a package you depend on.
Why can this not be expressed in the dependency information in the package?
I tried this briefly for a while when Setuptools first came out, and I
found it completely unmaintainable.
Say I have a package that represents an application. We'll call it
FooBlog. I release version 1.0. It uses the Turplango web framework
(1.5 at the time of release) and the Storchalmy ORM (0.4), and Turplango
uses HardJSON (1.2.1).
I want my version 1.0 to keep working. So, I figure I'll add the
dependencies:
Turplango==1.5
Storchalmy==0.4
Then HardJSON 2.0 is released, and Turplango only required
HardJSON>=1.2, so new installations start installing HardJSON 2.0. But
my app happens not to be compatible with that library, and so it's
broken. OK... so, I could add HardJSON==1.2.1 in my requirements.
But then a small bug fix, HardJSON 1.2.2 comes out, that fixes a
security bug. Turplango releases version 1.5.1 that requires
HardJSON>=1.2.2. I now have have to update FooBlog to require both
Turplango==1.5.1 and HardJSON==1.2.2.
Later on, I decide that Turplango 1.6 fixes some important bugs, and I
want to try it with my app. I can install Turplango 1.6, but I can't
start my app because I'll get a version conflict. So to even experiment
with a new version of the app, I have to check out FooBlog, update
setup.py, reinstall (setup.py develop) the package, and then I can start
using it. But if I've made other hard requirements of packages like
HardJSON, I'll have to update all those too.
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.
--
Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
