[Distutils] Buildout status

[Tarek Ziadé]

On Thu, May 12, 2011 at 3:28 PM, Jim Fulton <jim at zope.com> wrote:
> On Thu, May 12, 2011 at 6:56 AM, Tarek Ziadé <ziade.tarek at gmail.com> wrote:
>> On Wed, May 11, 2011 at 6:44 PM, Jim Fulton <jim at zope.com> wrote:
>>> On Wed, May 11, 2011 at 10:21 AM, Tarek Ziadé <ziade.tarek at gmail.com> wrote:
>>>> On Wed, May 11, 2011 at 3:21 PM, Jim Fulton <jim at zope.com> wrote:
>>>> ...
>>>> Not sure to folllow.  You want to port Setuptools into py3k... again ?
>>>>  If so, this was done already in Distribute, and you can join the
>>>> project.
>>>
>>> I don't really want to join a project. I already have a number of
>>> projects.
>>
>> But the work is not going to happen only into the zc.buildout tree,
>> right ?
>
> No. If I do this, I'd work with Phillip Eby.
>
> If you tell me that distribute is being actively maintained, I'll use
> distribute. What I've heard in the past is that distribute wasn't
> being worked on. I'd interpreted this to mean that it wasn't being
> maintained. Perhaps I misinterpreted. Again, if you assure me that it
> is being maintained, I'll use it instead.

I can't spend anymore the time on it regularly unfortunately, I have
to make choice about my free time and I chose to work in the stdlib
upcoming package.

But I can assure the following (that what happened lately) :

1- anyone that wish to contribute a patch can do it, I give commiter
writes for this
2- we are now several people that can push a release at PyPI. I can
add more people if I know them
3- When I do releases, I do post-review of patches
4- Some other folks have enough knowledge now to do 3.

There are a few patches pending that should be commited, and I am not
following Setuptools activity as I used too by a lack of time,
so there are probably a few commits to backport.

I think that's less of a day of work altogether as far as I can see.
I can spent this time real soon and do a release so we're up to date,
but you or someone else would need to help in the future.

I don't know if this is a superior approach to PJE's approach on
maintenanceship, but it means that any big issue that would happen in
the code will not be locked by a single person.

For instance OS packagers have an access to it, and can work out
problems they had downstream. I don't think we're anymore on the "no
one can understand the code base" line.


...

>>
>> I so wished that we could have all worked together in the first
>> place...
>
> What?  I don't understand.  You make it sound as if I refused to work
> with you.  If you are suggesting that I failed to contribute to
> distribute or distutils2, you'll have to excuse me for choosing to
> work on other projects. Buildout is just a consumer of setuptools (and
> packaging in the future).

Sorry for the confusion, I was not pointing any finger at you.  "we"
referred to all parties involved for packaging tools, setuptools,
distutils, distribute.

I was just indirectly saying that I also wished we did not forked and
be able to get along. But  I am still glad we did since we offered
setuptools for py3.

...
>> - what's going to happen when distutils2-based packages will be
>> published ? are you going to add backward compat in setuptools, so
>> redo what we did in d2 in reverse ? (this is planned in Distribute, so
>> doubled-work again)
>
> What I said was that I wasn't going to support both.

But if a project supports only distutils2 in the future, you cannot
force it to use setuptools' metadata.

Yet, it will express dependencies you need to deal with. (PEP 345)

...
>
> From talking to Phillip, I think he intends to update setuptools to
> reflect new peps.  Personally, I'd be happy to see it (and distribute)
> just fix bugs and remain stable.

I agree for bug fixing.

In the meantime I also partially agree w/ PJE:  package_resources
should be able to see packages installed by distutils2,
o/w that's not going to work well


>
> I'm totally on board with the move to packaging, but until all of the
> packages that buildout needs to install switch away from setuptools, I
> have to be able to provide setuptools support.

So do we. Packaging supports the installation of setuptools-based
projects, and also reading metadata from project installed by it.

...
>
> IOW, unfork. I would *love* *LOVE* to see that happen.

Me too, as long as we have more than one person on board  :)


>
>> - start to use in it, when possible, pieces of distutils2, so
>> Distribute/Setuptools become PEP 345/PEP 376 aware
>
> <shrug> sure. That's reasonable. First, buildout has to get under
> control. That's my problem (and the problem of people graciously
> helping me).
>
>
>> - stop adding features so distutils2/packaging slowly takes over
>
> Absolutely.  I couldn't agree more.  Just understand that we're going
> to have to support old packages that import setuptools in their setup
> scripts indefinitely.  That's one of the biggest challenges I see.
> Maybe packaging can (does?) provide a shim for this.

As I said earlier, we do have backward compat in everything we do with
packages. That leads to ugly code in some places, but we have to.

But as you said, there's the maturity problem...

Cheers
Tarek

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