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?
How do you decide that the version 1.2 of bar is the one you should use,
when you use the foo package that can work with any version of bar ?
If you are using no other packages that have a dependency on bar that
has a specific version requirement, then the answer is that you can use
any version of bar you desire.
You can define the version of foo, but can't describe all the versions of
the packages foo uses.
Why?
You'd end up building your own KGS in a way..
...you mean like the [versions] section with buildout?
Yes, I agree us paranoid people may want to do that, but we really
shouldn't need to provided the packages each correctly define their
dependencies...
So a general list of versions can help
I would be happy to wager that this would never successfully be maintained.
Bigger eggs wouldn't let you reuse thing like you can now imho
That doesn't explain the majority of eggs that end up dragging a whole
load of eggs down themselves. In this case, they should all be packaged
as one egg...
cheers,
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
