[Python-Dev] On track for Python 2.6.4 final this Sunday? (original) (raw)

M.-A. Lemburg mal at egenix.com
Tue Oct 13 17:42:32 CEST 2009

P.J. Eby wrote:

At 08:27 AM 10/13/2009 -0400, Barry Warsaw wrote:

Are we on track to release 2.6.4 final this Sunday or do we need another rc?

Yesterday, Tarek committed another setuptools related fix and said that he was going to run a bunch of build tests locally. Tarek, how did that go? FWIW, that change won't work to fix the problem on Windows if a package's setup.py is written with cross-platform paths (i.e., the usual case). Also, for the record, it's not really a setuptools-related fix; it's just attempting to fix collateral damage caused by the attempt to fix the problems caused by the original API change... which affected all buildext customizations relying on the docstring of the changed method, not just the one in setuptools.

Just to clarify a bit what all the fuzz is about:

The API in question (build_ext.get_ext_filename()) was not changed at all. The doc-string also doesn't refer to the extension currently being built, but to just to some arbitrary extension:

def get_ext_filename (self, ext_name):

    r"""Convert the name of an extension (eg. "foo.bar") into the name
    Convert the name of an extension (eg. "foo.bar") into the name
    of the file from which it will be loaded (eg. "foo/bar.so", or
    "foo\bar.pyd")."""

What did change is the way this method is used by other methods in build_ext: the method is no longer being called with the full dotted name, but only with the last component.

Now, setuptools and pywin32 both override the method, with the understanding that this method is the one and only way to convert the extensions (full) dotted name into a file name.

Up until the change (which was needed to get inplace installations working), that assumption was true. However, neither the doc-string nor the implementation of the method ever implied this.

distutils occasionally makes such assumptions necessary since there's no clean OO-way to override the functionality. That's not ideal, but works most of the time.

However, authors of distutils add-ons cannot really expect such hacks to survive forever.

Rather than relying on these, it's better to get distutils fixed to provide the necessary OO-hooks to properly implement the modified functionality.

FWIW, I've had to change and tweak our mxSetup.py many many times to get it to work again with new distutils releases and I expect this to occur even more often now that distutils is finally being maintained again - and that's good, since I'll be able to get rid off the few remaining hacks !

-- Marc-Andre Lemburg eGenix.com

Professional Python Services directly from the Source (#1, Oct 13 2009)

Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

More information about the Python-Dev mailing list