[Distutils] Reverse dependencies
Jim Fulton
jim at zope.com
Mon May 14 21:11:59 CEST 2007
On May 14, 2007, at 3:02 PM, Martin Aspeli wrote:
> 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. :)
>
> Interesting. :)
Hey, I have lots of things to do. I have to prioritize. :)
BTW, please don't request this until you really need it.
>> 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+
> either.
>
> 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.
I was just trying to note in a round about way that I prefer the
simpler model of dependencies. We don't need to introduce a new
concept. We just need a better version-resolution algorithm. We're
going to need this sooner or later regardless of whether we have
anything that someone might choose to call a platform.
Note that having such an algorithm is more practical for buildout
than with easy_install because the resolution is done at install
time, rather than at run time, and can thus take longer if it needs to.
jim
--
Jim Fulton mailto:jim at zope.com Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
More information about the Distutils-SIG
mailing list