On Wed, May 11, 2011 at 6:44 PM, Jim Fulton <[email protected]> wrote:
> On Wed, May 11, 2011 at 10:21 AM, Tarek Ziadé <[email protected]> wrote:
>> On Wed, May 11, 2011 at 3:21 PM, Jim Fulton <[email protected]> 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 ?
>
>> Or you want to copy our work from Distribute back into Setuptools ?
>> I would not mind of course, merging back the 2 projects would be
>> awesome -- but I have no hopes on this.
>
> It's possible that I could reuse that work. I'd rather port to 2&3
> rather than 3. That is, I'd rather not rely on 2to3 at deployment
> time. I find installing distribute in Python 3 to be really annoying
> due to the spew from 2to3. I also find the 2to3 development model
> really unattractive.
The major benefit is that you don't have to maintain separate branches
for py3. Another thing is that you often don't have to deal with 2to3
internals, as you just adapt your code to be 2to3 friendly
I agree that extending 2to3 is tough, but that almost never occur. If
it occurs, you just need to ask Lennart ;)
And the benefits are larger than going manually. We tried ! I don't
see the extra spew at install time as a problem.
>
>> Although, my suggestion would be to start digging into the
>> Distutils2/packaging project instead, since that will be in the
>> standard library, and backported in 2.x.
>
> When it's mature, I'll use it.
Some of the code you need is usable today.
examples:
- easy_install's package index can be replaced by the index tool we have.
- browsing installed packages (the new PEP 376 and the old
setuptools/distutils standards)
- ...
There are a few corner cases we don't deal with. For instance, we get
things installed as non-zipped egg. I think that would be a good
default for buildout2.
But yeah, the code is not "mature" I guess, but it's driven by known
use cases for you, not new features we'll ask people to try out. And
it's going to be published in Python 3.3 in +1 year. Not sure what
your roadmap looks like but if buildout2 is a rewrite, by the time its
mature itself, 3.3 will be out imho
>
>> I believe it provides all the features buildout needs. And if not we
>> should add them
>
> Buildout needs entry points.
Entry points are just a feature on the top of browsable metadata of
installed packages. The browsable part is already provided by d2. The
installation of custom metadata is going to be
done this summer during the GSOC, Basically, a CUSTOM file in the
metadata directory. With a backward compat layer to install entry
point as custom metadata.
In a new Python3.3/packaging based projects, people will be able to
add in their setup.cfg file:
[metadata]
X-Entry-Points =
group:name = here.it.is
And this will be copied in project.dist-info/CUSTOM
In fact the plan is to *publish* setup.cfg to PyPI so tools will be
able to read it without downloading anything !
For you, it means that you could use a single API to browse metadata
for every installed project, whether they are setuptools-based or
distutils2-based.
>Regardless, I fully expect to use
> Packaging when it's ready, but I'm stuck with setuptools/distribute
> now. I so wish that fork hadn't been done.
I so wished that we could have all worked together in the first
place... On my side, the plan was to extend Distribute but that did
not happen there, as we discussed the options in the Language
Summit(s)
and imo that was a good decision. Now I am looking forward to the new tools.
But the reality is that some projects can run under Python 3 thanks to
Distribute. It's now used in most major Linux distributions, and you
saying "I will not support anything else that setuptools in buildout2"
does not sound right to me. By taking the road you've mentioned, it
seems to me that it's going to be more work and trouble that you
expect because:
- you are going to re-do all the py3 porting we already did, and that
needs backward compatibility w/ distribute, because some people use
it for the extra python3 features we added
- you are going to maintain several branches if you don't use 2to3
- 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)
A simple direction in my opinion would be:
- make sure all stuff done on setuptools lately that were neglected on
distribute side get merged back - so we really have 100% identical
behavior that works under py3
that's *way* less work.
- use when possible, pieces of distutils2 in buildout2, since we
target backward compat for all our APIs.
Because as far as I know, the Setuptools project is just doing
bugfixing. I don't think there are yet new features in it. I consider
that all setuptools-related technologies are now superseded by the new
stuff we do in packaging (that greatly inherit from them)
An even most simple direction, which would be for the best for all --
but that's not going to happen I guess :
- merge Distribute and Setuptools projects in the same codebase, and
have more people maintaining it. It's a mutual benefit. Features added
in Distribute are not controversial. (per-user easy install support,
py3 support)
- start to use in it, when possible, pieces of distutils2, so
Distribute/Setuptools become PEP 345/PEP 376 aware
- stop adding features so distutils2/packaging slowly takes over
>
>> I think it boils down to: we should *all* work together in the
>> Distutils2/packaging project for all the basic packaging features we
>> need in third-party tools.
>
> I have lots of interesting projects I am working on and want to work
> on. I have no interest in making packaging a career.
We're all on the same page here. And it seems to me that you're
planning quite a packaging career in buildout2 ;)
> I'll use
> Packaging when it's ready. In the mean time, lots of people need
> buildout to work with Python 3 today.
So imho you should take the shortest path to this goal, but in the
meantime without ignoring what's coming next -- because you'll want to
use d2-based projects in buildout2 quite soon
Cheers
Tarek
--
Tarek Ziadé | http://ziade.org
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
