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. > 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 _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
