[Distutils] Reverse dependencies
optilude at gmx.net
Mon May 14 21:02:45 CEST 2007
Jim Fulton wrote:
> FWIW, I expect to have to implement this for buildout at some point.
> I don't plan to do it until it becomes a priority. :)
> WRT platform, I see this as an anti-solution. Fortunately, it looks
> like it has already been dismissed. :) The reason I see this as an
> anti-solution is that we already have a platform, namely Python 2.4,
> that might be better treated as a dependency. For example, there
> isn't a way, AFAIK, to state Python version requirements for source
> releases. I think it might be cleaner if things like Python version
> and maybe even size of unicode characters could be handled using the
> dependency mechanism.
To me, the word "platform" means more than Python version and low-level
OS things. I also meant things like "Plone" or "Zope". I'm not saying
these can't be handled by dependency backtracking, but it may be more
practical to think in terms of some higher level constructs.
For example, if I develop a package for Plone, I may target Plone 3,
test with Plone 3.0.x and know that it works with 3.0.1.
However, I may not have any direct dependencies on Plone - the package
could be more general, but other things used in Plone may mean that I
know it works with 3.0.1 but no earlier versions, and possibly not 4.0+
In a perfect world, entirely strict dependencies should tell us all
this. However, in practice, since things like Plone and Zope are
released as whole units, and not necessarily managed strictly as a
system of with eggs requiring each other (which, for something like
Plone, could end up being quite complex to manage), that may not work.
The algorithm to find them could be pretty hairy as well.
As the builder of an application on top of Plone, all I really want is
"the version of the package that works with Plone 3.0.2" (or whichever
version I'm using). In this case, such "known-good platform" metadata
may be quite useful.
More information about the Distutils-SIG