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

[Jim Fulton]

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.

...

> but how would you handle the install_requires field in zc.buildout ?

It would have to leave setuptools out of buildout's install_requires.
In general, if a package depends on any one of multiple dependencies,
I'd be inclined not to list the dependencies, but leave it up to the
installer to provide one.

...

>>  That seems cleaner and less brittle
>> than hacking installed setuptools distributions.
>>
>
> 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?

> 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.

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.

Here are some more specific thoughts:

Problems that I'd like to see solved:

- distutils doesn't currently provide a mechanism for tracking
distribution dependencies

- distutils doesn't allow extensible meta data.

- setuptools doesn't work with Python 3.

- setuptools has insane dependencies on revision control tools.

Here's how I'd solve these problems if I had enough time:

- I'd write a new tool to create packages.  This tool would only
create packages.  It would read static meta-data files and generate
setup.py and manifest files that don't depend on setuptools.  (It
might only be suitable for 97% of packages that need to be
distributed.) It would invoke the generated setup script to build
distributions.  It would cause egg-info directories to be included.
It would build on the egg-info "standard" established by setuptools.
It would not get involved with the distutils command framework in any
way. I'd work with Phillip and Ian to make sure these packages could
by consumed by easy_install and pip. Of course, I would make sure that
buildout could consume them.

- 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