Skip to content

Setuptools on Python 3: Work on hold.

April 21, 2009

Edit: Distribute now supports Python 3. This posting is therefore outdated and no longer of interest. Go away. :-)

I’ve currently suspended the work on porting Setuptools to Python 3. If you need it, there is the version I made earlier on the Python-incompatibility project page. It seems to work. If people want to fix bugs you can still mail me and I’ll give you access to fix it. It’s very unlikely that it ever gets merged.

Why? Well, it basically comes down to that setuptools code is messy and hard to understand and Phillip J. Eby argues against all efforts of improving it. That gives me three options: Fork setuptools, rewrite it from scratch, or give up. I don’t want to fork it, mainly because I don’t think the code is good enough to be worth forking. It’s so hard to maintain, that if we need to fix it without Philip J Ebys support, it’s probably easier to rewrite from scratch. But… I can’t rewrite it from scratch, I simply do not understand the issues well enough to do that. So, at least for the time being, I give up.

This means that there is no official setuptools release. That means it’s going to be hard to port and install any python module using setuptools. This is probably the majority of Python modules on PyPI, because the biggest creators of Python modules is Zope/Plone and these modules all use setuptools. This of course also means that my porting of zope.interface that I started is on hold. In fact, it means all my Python 3 porting work is on indefinite hold. Setuptools is currently the major obstacle for widespread acceptance of Python 3. Sad but true.

So what are the alternatives if you want to port to Python 3? Well, first of all, if you use setuptools, get rid of it. If your module only uses distutils, you can port it to Python 3, and have 2to3 run automatically by using build_py_2to3 in place of build_2to3. It can often be quite a pain to move a project that uses many setuptools features to plain distutils, but currently I can’t recommend using setuptools if you plan to move to Python 3.

If you feel you really need setuptools functionality in your project, join distutils-sig@python.org, and discuss how we can solve the situation. Right now I feel that the most likely way forward is to rewrite setuptools, and possibly also distutils, from scratch.

About these ads
9 Comments
  1. I am a bit upset (don’t get me wrong it’s not personal) because you were present at the summit and heard what we said on Distutils.

    For Distutils: until you sit down and work with us on the PEP we are building and real uses cases to make things better, you are just part of the people that are just saying “it sucks let’s ditch it, let’s redo it from scratch” That is not helping much.

  2. Tarek, I have been dragged into the distribution/packaging area completely against my will, and wasn’t able to contribute much to that discussion, I did however, as did others there, voice my concern about breaking backwards compatibility while still retaining the name distutils. This concern remains. That’s why I wrote “possibly also distutils”.

    However, the main concern of this post is clearly not distutils, but setuptools. And I do feel that at the moment, the best way forward with setuptools is to rewrite it. And possibly also distutils.

    Redoing from scratch *is* helping, if it’s easier to do so than to fix the issue. I don’t know if this is the case with distutils. I think it probably is with setuptools.

  3. The knowledge in that code is unfortunately inaccessible as the code is hard to understand and not documented, making it very hard to maintain.

  4. > Redoing from scratch *is* helping

    I thaught too at first, but after 1 year now of work within distutils,
    now that I understand most of the code, I changed my mind

    > It’d be a waste to throw away all the knowledge that exists in the code.

    Right. Guido agreed on that and the plan is to make it a better citizen for Python 2.7

    For Distutils the fact that is unreadable and untested is less and less true because I took over its maintenance and added tons of tests.
    There’s still a whole lot of work for sure : for instance, I didn’t get into the Distribution class yet, or in the binary commands.

  5. Right. Again I want to point out, to lessen the possibilities of misunderstanding: This post is about setuptools. NOT distutils.

  6. Attila Oláh permalink

    May I ask a question here?

    Almost three months have passed, is there any further development going on to port Zope 3 (or at least some of the zope.* modules) to Python 3? I’d like to have a minimal wsgi application that uses Zope 3 libraries, run by Python 3(.1). However, it seems that there’s not much of Zope available for Python 3. Looking at the dependency graph, it seemed to me that if I start at the bottom, the first thing to port would be zope.interface. That’s how I got googled here :)

    I’m not sure about how Python 3 module packaging work, is setuptools still the way to go, or is there something new on the horizon?

  7. There is nothing of Zope available for Python 3. It’s being blocked by the same thing that blocks most Python 3 development: setuptools doesn’t support Python 3 properly. Progress on this has in turn been blocked by Philip J Eby for many months now.

    However, now there is progress. We are simply taking over setuptools. As we can’t relase it to PyPI under the name setuptools, it’s being rebranded. As with all packaging discussions, the name of the fork is lost in bikeshedding, but it looks like it’s going to be “Distribute”. I’m hoping to get Python 3 support into the main branch within a couple of weeks, but I do not currently remember when the plan is to make that sort of release. (There will be a bugfix release probably next week, but that will not support Python 3). Once the Python 3 compatible release is out, work on zope.interface can continue.

    Your help, both on zope.interface and Distribute, would be most welcome.

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

    http://mail.python.org/pipermail/distutils-sig/2009-July/012512.html

  8. Update: Distribute now supports Python 3. There is a working zope.interface fork as well.

Trackbacks & Pingbacks

  1. Python 3.1.1 + Distribute + Mod_WSGI Available For RHEL/CentOS 5 « IUS Community Project

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 1,285 other followers

%d bloggers like this: