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

[Martijn Faassen]

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.

> 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 version
list over HTTP?

I also don't understand why you say I'm asking for it to work without 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.

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

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.

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.

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.

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.

Regards,

Martijn