[Zope3-dev] Re: Known working sets II [was: Eggification redux]

[Jim Fulton]

On Sep 25, 2007, at 11:22 AM, Martijn Faassen wrote:

> Hey,
>
> On 9/25/07, Jim Fulton <jim at zope.com> wrote:
> [snip]
>> I'm skeptical that you are going to get these changes in setuptools.
>> I'm not crazy about them myself as they make writing setup files even
>> more complicated.  I'd much rather have a way for a comsumer to say:
>> "Use version V of project P even though it doesn't satisfy a
>> dependency."  Basically, a way to override a dependency.  This is
>> something that buildout could be taught to do, although *I* don't
>> have time to do it "today".
>
> That solves the problem too.
>
> Should we then encourage everyone to hardcode version numbers in their
> setup.py's dependencies list? If not, framework packages can maintain
> such lists.

No, only in "application" (or very thick framework packages).

This should certainly not be done for library packages.


>> OTOH, buildout already provides an alternate solution to this, which
>> isn't good enough because you want something that will work w/o
>> buildout.  Oh well.
>
> I am not sure what buildout mechanism you're referring to.

A buildout configuration can specify a versions section that  
specified the versions to be used in the buildout.  Other buildout  
configurations can extend the original configuration, specifying  
different versions as desired.,


> A version
> list over HTTP?

Configurations can be specified as URLs.  Anything that urrlib2  
understand will work. For example, you can include URLs in a buildout  
extends option.

> I also don't understand why you say I'm asking for it to work  
> without buildout.

You aren't?  Cool. Well, other people have.  When this issue first  
came up, Philipp worked out the buildout solution and others  
complained they wanted something that would work with workingenv,   
I'm not saying that this is an invalid desire.  I'm just pointing out  
that there is a solution of you're willing to use buildout.


> The requirement is that not the application developers but the
> framework developers are easily able to maintain this list of
> dependencies. That is:
>
> * if someone puts the depencency to framework 1.7 in their
> dependencies in setup.py, it'll automatically get the pinned
> dependencies of this framework.

Well, the buildout solution won't help that.


> * if someone tells us, we used framework 1.7, we *know* what
> dependencies this implied (unless they did a manual override).

If reusing the framework includes reusing a buildout configuration  
that specifies the versions used by the framework, then buildout can  
help.

> So, if I write an application that uses framework 1.7, all I should
> have to do is set this in my dependencies list in setup.py. If I then
> decide to upgrade to 1.8, that's all I need to adjust. There is no
> long list of dependencies for me to maintain, as the framework
> developers do this for me. It'd be nice if I had the ability to
> override what the framework said, of course.

setuptools doesn't let you do this. Maybe you want to lobby for a  
change on the distutils sig.

Buildout could be enhanced to provide this feature, as I mentioned  
before.


> I know you referred us maintaining a buildout versions list on some
> HTTP site. This indeed solves most of the above. I don't think this
> ideal:
>
> * it doesn't work in a train. Of course, egg downloads don't either,
> but at least one tends to have a well-filled eggs directory already.
>
> * it requires the developers to upload a new list to some HTTP site
> each time they make a framework release. With eggs, it's nice that a
> few setup commands are all you need to do to make a release. So, I'd
> prefer to maintain this list in the package the list is talking about,
> and to only have a single release artifact (the package itself),
> instead of two (the package and the list).
>
> Of course, since it works now, we might want to do this for now
> anyway. I just don't think it's ideal.

Agreed.

> Would it be possible for buildout to retrieve such a list from an egg
> if it's maintained as an extra, made-up setup.py variable? I just
> tried this, but it doesn't seem to be stored in egg-info.

In theory, but not today.  Your use case would be better served by  
adding a way to tell buildout to use a package version even if it  
violates some requirements,

> Finally, it would be nice to have the ability to maintain multiple
> lists of dependencies of significant sub-frameworks, and to have the
> ability to combine them in larger frameworks. That is, someone could
> be maintaining a Zope3-core package that depends on a whole bunch of
> Zope 3 packages, and Grok would then depend on this. I'd be nice if
> Grok wouldn't need to maintain its own list of pinned Zope3-core
> packages in this case but could rely on the release management and
> integrated testing procedure of the package it depends on. This is all
> "would be nice" right now, though.

I think there are lots of potential complexity that all this  
flexibility could add.  I'm not sure how "nice" that would be.

In any case, you should probably raise this issue on the distutil-sig  
list.

/me goes to get popcorn.

Jim

--
Jim Fulton
Zope Corporation