On Sep 25, 2007, at 11:22 AM, Martijn Faassen wrote:
Hey,
On 9/25/07, Jim Fulton <[EMAIL PROTECTED]> 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
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
