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

[Martijn Faassen]

Hey,

On 9/27/07, Tres Seaver <tseaver at palladion.com> wrote:
[snip]
> > Why don't you think it can be solved by having packages themselves
> > state preferred versions? The cheeseshop can be a festering pool of
> > madness, as long as the packages I pull from it have reasonable
> > preferred versions, I should be fine, right?
>
> A few things:
>
>  - Your solution requires a new feature in setuptools, whose development
>    velocity has dropped off pretty sharply of late.  Maybe you've got a
>    patch in hand already, at which point you could offer a temporary
>    fork while the feature makes it way into an official release.

Yes, my solution takes time. So does setting up a gated community and
making it work.
Meanwhile using explicit 'versions' over a URL in buildout.cfg is a
good enough hack to make it work with the cheeseshop today.

>  - The proposed feature makes solving the package dependency graph
>    harder, rather than easier:  what if grok recommends a different
>    version of 'zope.interface' than some other component recommends?

You don't get conflicts if you use 'or'. You just get different
preferred versions. The outer package wins, so Grok would win if that
includes the other component. If it wants to delegate this to the
other component it shouldn't specify a preferred version.

>  - People do remove releases from the Cheeseshop, with various
>    justification.  If you want to guarantee that somebody will be
>    able to recreate the known environment, even in the face of missing
>    distributions, you have to mirror the "blessed" distributions.

This is all very nice, but a gated community *don't solve my problem*.
I want to be able to release something, and then have people install
it with the same dependencies, and this should *never* break. A gated
community will *still* feature botched new releases, upgrades to 3.5
packages that suddenly get pulled in by my package, etc. You could do
this if you have a community *per project*, and the maintenance
overhead goes through the roof. I want to use my 'python setup.py
sdist upload'.

It also yet again introduces pulls us into our own community next to
the Python community, just as we started to engage with the
cheeseshop. I think that would be a very regrettable development and
I'm very much against it.

Regards,

Martijn