[Distutils] Distribute and zc.buildout + bootstraping file names + release/branches roadmap

[Tarek Ziadé]

On Wed, Aug 5, 2009 at 2:14 PM, Jim Fulton<jim at zope.com> wrote:
> On Tue, Aug 4, 2009 at 5:57 PM, Tarek Ziadé<ziade.tarek at gmail.com> wrote:
>> On Tue, Aug 4, 2009 at 11:43 PM, Jim Fulton<jim at zope.com> wrote:
>>>
>>> Buildout will often reinstall setuptools, depending which version it
>>> thinks it needs. I'd expect this to defeat whatever you've done.
>>
>> Distribute "installs" setuptools 0.6c9, so unless buildout tries to
>> downgrade setuptools,
>> it should not defeat it,
>
> buildout will downgrade if an older version of setuptools is specified
> in a versions section or in the setuptools-version option.
>
>> Do you have a scenario in mind I can try ?
>
> Read the tests for upgrading, which include downgrading.

Then it means that the user explicitely downgraded setuptools in its buildout
cfg file, which is a case that I am not handling : if people want to
use distribute they'll have to fix their cfg.

>> Unfortunalety, even outside zc.buildout, I don't see any other
>> solution than setting up a "fake" setuptools,
>> to avoid changes in third party softwares, like their "install_requires" field.
>
> I don't agree with this goal. Why not let 3rd-party developers add
> support for distribute explicitly.
>
> Can you explain why buildout *should* use distribute at this point?
> What's in it for buildout users?

to benefit from all the bug fixes we did of course,

http://bitbucket.org/tarek/distribute/wiki/bug_listing

And I am not expecting +250 distributions and more to switch like that,
being able to switch without changing anything except the bootstrap and
the cfg file(s) and work on already existing distributions (plone.*, zope.*)
is a major win.

If we don't do this, it'll take months or more for all dependencies
to get released again.

We want to the fixes *now* then work on a better implementation.


>
>> I see the 0.6 version of Distribute as a hack in any case, until
>> Distribute 0.7 change the package/modules names,
>
> So Distribute 0.7 won't be backward compatible with 0.6?
>
>> If anyone think about a better plan for the switch, speak up :)
>
> If you think you can do better than setuptools, I think you should
> come up with a different tool that has a different name.  You
> shouldn't try to trick applications into running your tool.

Distribute 0.6 is the will-never-be-released setuptols 0.6
I don't want  people to have these two only choices:

- stick with setuptools that has not changed for +9 months
  and wait for an hypotetical release
- wait for a distribute completely rethaught 0.7 version
  wait for zope, plone and al to switch on it

With distribute 0.6 it allows people to have an upgraded setuptools-like
distribution that allows them to use the existing, release softwares.

So unless someone else strongly opposes to this plan, this version
will be released nevertheless.

I believe the Plone community waits for it.

>
> My own view is that we shouldn't try to fork setuptools, but should do
> something different and much smaller.  I think setuptools is far more
> ambitious than it needs to be.

That's the plan for Distrtibute 0.7 too (having several ditinct distributions)

> Here's how I'd solve these problems if I had enough time:
> [...]
> ... I'd work with Phillip ...

As you might have noticed, Phillip doesn't have the time anymore to work
on setuptools code base. This was why we started this fork: to unlock the
community from this bottleneck situation.

So I don't see how we could solve anything if we work with a project
that doesn't
make anymore change, and that is owned by someone who doesn't have
the time and who is not willing to let us work in it.

With all respect to PJE, my opinion is that this locked situation demonstrates
that the community needs to move away as soon as possible from the setuptools
project because it's not community-driven neither in the spirit of open source.

What I mean by "open source spirit" is :

It's ok (and probably a good idea) to have a dictator in a open source
project, but it's not OK when the dictator
is AWOL, which is the case right here. When it happens, a fork is needed,
unless the dictator gives the key of the locker to other people (that
have some time in turn of course)

For instance, you are the zc.buildout dictator, but you have unlocked
its maintenance to
the community because (that's what I have understood) you don't have
the time anymore
to work on it, and you think it's stable and advanced enough, and
because you *trust* the zope community
will eventually do a good job.

I am disappointed this scenario didn't happen with setuptools, because
that's what I'd have expected.


>
> - I'd (will) update buildout to not use setuptools.  It doesn;t use
> much of setuptools now.  It would be great if we could come up with a
> much smaller install library that multiple packages could share.
>
> Jim
>
> --
> Jim Fulton
>



-- 
Tarek Ziadé | http://ziade.org