Mailman 3 October 2009 - Distutils-SIG

Distutils 0.6.4 this week
by Tarek Ziadé 07 Oct '09

07 Oct '09

Hello, We are going to ship Distribute 0.6.4 by the end of this week with a few more bugs fixed, whereas they were listed in Setuptools tracker (http://bitbucket.org/tarek/distribute/wiki/bug_listing) whereas they were added directly in our tracker. If you had any issue you want to see fixed in this release, please speak up. If you want to help, you can install and play with the nightly build of 0.6.4 by running: http://nightly.ziade.org/distribute_setup_dev.py Last, a new wiki page has been added where we are giving more details on the roadmap for 0.6.x and 0.7.x : http://bitbucket.org/tarek/distribute/wiki/roadmap Regards Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与

2 1

Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute
by Ronald Oussoren 07 Oct '09

07 Oct '09

On Monday, 05 October, 2009, at 11:53AM, "Lennart Regebro" <regebro(a)gmail.com> wrote: >2009/10/5 Jeff Rush <jeff(a)taupro.com>: >> Very unfortunate, as in, it should NOT have happened. And *especially* >> without any announcement on python.org or mention on the >> python-committers list of something this major. > >Well "this major"... It's a bug fix that breaks a setuptools monkey-patch. >But yes, it was discovered before release, and maybe it should have >been discussed, I'm not on python-dev anymore. I agree with Jeff that this shouldn't have happened, or should at the very least have been documented in the release notes for 2.6.3. I know of several users of Python that have been bitten by this (they installed 2.6.3 and now easy_install doesn't work anymore for them). For beginners this issue is a showstopper that they cannot resolve without help. > > >> Distribute is very new and there are many folk who will not be adopting >> it until it has been out for quite some time. > >Nobody will adopt it until they are forced to. This unfortunate bug >means people are forced to quicker than expected. I don't think that's >an actual problem. This is a problem, it means 2.6.3 is not a simple drop-in replacement for 2.6.2 but requires the replacement of another component as well. That can be a problem in organizations with strict configuration management where you cannot install new software without going to lots of red tape (and that might involve lawyers when you install a new package instead of upgrading an existing one). Ronald

15 28

Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute
by P.J. Eby 06 Oct '09

06 Oct '09

At 11:53 AM 10/5/2009 +0200, Lennart Regebro wrote: >2009/10/5 Jeff Rush <jeff(a)taupro.com>: > > Very unfortunate, as in, it should NOT have happened. And *especially* > > without any announcement on python.org or mention on the > > python-committers list of something this major. > >Well "this major"... It's a bug fix that breaks a setuptools monkey-patch. Subclassing distutils commands != monkeypatching. If, say, numpy's distutils extensions subclass build_ext and override that method, they could have had the same problem. Same for anybody else's distutils extensions.

3 3

Distribute install problem on Snow Leopard
by Ralf Gommers 06 Oct '09

06 Oct '09

Hi, I installed Distribute on a Snow Leopard box using the default Python that comes with OS X. I used the installation method recommended in the docs, the distribute_setup.py script. Now easy_install fails no matter what package I try to install (it does not get around to looking for the name of the requested package): $ easy_install blablabla Traceback (most recent call last): File "/usr/bin/easy_install-2.6", line 10, in <module> load_entry_point('setuptools==0.6c9', 'console_scripts', 'easy_install')() File "/Library/Python/2.6/site-packages/distribute-0.6.3-py2.6.egg/pkg_resources.py", line 281, in load_entry_point return get_distribution(dist).load_entry_point(group, name) File "/Library/Python/2.6/site-packages/distribute-0.6.3-py2.6.egg/pkg_resources.py", line 2197, in load_entry_point raise ImportError("Entry point %r not found" % ((group,name),)) ImportError: Entry point ('console_scripts', 'easy_install') not found Did I forget something, or is this a bug? Any suggestions on how to fix it? Cheers, Ralf

2 5

[ANN] stdeb 0.3.2 and 0.4.1
by Andrew Straw 06 Oct '09

06 Oct '09

stdeb produces Debian source packages from Python packages via a new distutils command, sdist_dsc. Automatic defaults are provided for the Debian package, but many aspects of the resulting package can be customized via a configuration file. An additional command, bdist_deb, creates a Debian binary package, a .deb file. stdeb: http://github.com/astraw/stdeb This email announces releases 0.3.2 and 0.4.1. release 0.4.1 download: http://pypi.python.org/pypi/stdeb/0.4.1 release 0.3.2 download: http://pypi.python.org/pypi/stdeb/0.3.2 Release 0.4.1 adds new features, conveniences and bug fixes to the recently released, but unannounced 0.4 release. These two releases move stdeb to use debhelper 7 (and therefore require at least Ubuntu Intrepid, Debian Lenny, or the use of backports). This use of debhelper 7 allows the auto-generated debian/rules file to be greatly simplified. stdeb 0.4 also switches to python-support from pycentral. If you do not need to migrate packages from earlier versions of stdeb, it is recommended to use the "--pycentral-backwards-compatibility=false" command-line argument. See the changelog[1] and release notes[2] for more information. [1] http://github.com/astraw/stdeb/blob/release-0.4.1/CHANGELOG.txt [2] http://github.com/astraw/stdeb/blob/release-0.4.1/RELEASE_NOTES.txt Release 0.3.2 (and the unannounced 0.3.1) are maintenance releases for the old-stable branch, which works with older distributions such as Ubuntu Hardy. These releases added the bdist_deb command. See the changelog[3] for more information. [3] http://github.com/astraw/stdeb/blob/release-0.3.2/CHANGELOG.txt As always, the venue for discussion of stdeb is the distutils mailing list at http://mail.python.org/mailman/listinfo/distutils-sig Thanks to all who have helped stdeb for these and previous releases: Authors ------- * Andrew Straw <strawman(a)astraw.com> * Pedro Algarvio, aka, s0undt3ch <ufs(a)ufsoft.org> * Gerry Reno (initial bdist_deb implementation) Additional Credits ------------------ * Zooko O'Whielacronx for the autofind-depends patch * Brett (last name unknown) for the --ignore-install-requires patch * Ximin Luo for a bug fix * Alexander D. Sedov for bug fixes and suggestions * GitHub for hosting services. * WebFaction (aka python-hosting) for previous hosting services. -Andrew

2 2

distutils: packaging a generated configuration file
by Mark Dickinson 05 Oct '09

05 Oct '09

I'm trying to use distutils for the first time to package up a project, and struggling a bit; I wonder whether some kind soul could point me in the right direction. I'm packaging a pure Python project that uses ctypes. The only complication is that I'd like the setup script to install a configuration file alongside the various .py files. From the documentation, this sounds like something that would usually be specified with 'package_data' or 'data_files'. The catch is that parts of the configuration file are generated at setup time: that is, the setup script gathers various pieces of system information (e.g., library locations) and uses those to transform a hard-coded 'config.in' file into the 'config' file that I want to install. I could just generate the 'config' file in the top-level package directory, but it seems dangerous to assume that that directory is writable; it seems better to use one of the build directories that distutils already knows about. What's the best way to manage generation and installation of the config file? I've got as far as subclassing the build command and making __run__ create the config file from the config.in file, putting it into the build_temp directory; I can't figure out how to tell distutils to install it in the right place. It seems like I want a sort of build_data/install_data pair of commands, that allows creation and installation of *generated* data files. Any hints? Mark

2 1

Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute
by P.J. Eby 05 Oct '09

05 Oct '09

At 06:53 PM 10/5/2009 +0200, Lennart Regebro wrote: >Possibly if you somehow >think it's the Distribute teams fault that a bugfix in Python ended up >breaking setuptools. If it would have been better not to fix that bug, >then the blame reasonably goes to the Python core developers, not the >Distribute team. In this case, though, the "Python core developer" is also the Distribute lead. (i.e., it was Tarek who made the changes to the distutils.) So it's a bit understandable that some people might wonder if there was a conflict of interest. I don't personally think that's the case; it's pretty much inevitable that the distutils making progress means other things will break. But it's easy to see how others might take the situation another way, or treat it as an example of Distribute policy towards backward compatibility, or of what kind of breakage is considered acceptable in a dot release. It would be good to bear in mind that extending the distutils (or setuptools) is *not* monkeypatching; both libraries provide explicit assurance that subclassing is in fact allowed. And there's nothing all that special about setuptools' subclassing of build_ext; in fact, if you look back in the archives here, other people have done equivalent subclassing to support dynamic library building. I haven't checked their code, but there is a strong possibility that it would also fail in the same way. This is not really about monkeypatching, or about special support for setuptools.

2 1

Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute
by P.J. Eby 05 Oct '09

05 Oct '09

At 07:53 PM 10/5/2009 +0200, Hanno Schlichting wrote: >If I understand the comments on this ticket correctly, Tarek has >changed distutils in a way so the last setuptools release continues >to work, correct? Yes. And a very nice fix, done quite quickly. Thank you Tarek. >So based on the current state of Python 2.6.4 will work again with >an unmodified setuptools 0.6c9? AFAICT, that is correct.

2 1

Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute
by P.J. Eby 05 Oct '09

05 Oct '09

At 04:57 PM 10/5/2009 +0200, Lennart Regebro wrote: >2009/10/5 Barry Warsaw <barry(a)python.org>: > > I apologize for my part in this, but moving forward I think that if it's > > possible to patch and release a setuptools that works with Python 2.6.3 > > /and/ earlier Python 2.6.x's, then that should happen asap. > >PJE seems interested in this, as he asked about a patch, so maybe. I expect to have a small amount of time later this week to work on setuptools. No guarantees, but this is certainly one of the bugs on my short list for doing something with. > > If that's not possible, then we might need to revert the distutils > > change in a quick Python 2.6.4. > >That would be a big mistake. Actually, I think the mistake here is where non-bugfix code was ported from 3.x back to the 2.6.x maintenance branch. I'm particularly concerned about the .compiler / ._compiler change, as it seems to me to be responsible for breaking mingw32 compilation on Windows, but I haven't had time to investigate thoroughly. (It actually looks like a problem that might be in Python 3 as well.)

1 0

how to build location-independent bdist packages on OS X?
by Bill Janssen 05 Oct '09

05 Oct '09

I'm trying to bundle up a Python package with a C extension in it for Python 2.6 on an OS X 10.6 system. I don't want to install it in the normal /Library/Python/2.6/site-packages/ location. But when I try "python setup.py bdist", it builds a tar file with the prefix /Library/Python/2.6/site-packages as a prefix to each file. I then tried "python setup.py bdist_dumb" with the same result. I then tried "python setup.py bdist --prefix=.", but "--prefix" isn't recognized by bdist. What's the appropriate magic here? Oh, and I don't want to have to use setuptools. TIA, Bill

1 0