Mailman 3 January 2006 - Distutils-SIG

IRC?
by Jim Fulton 15 Jan '06

15 Jan '06

Is there an IRC channel that people knowledgable about setuptools hang out on? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

2 1

eggs in Python path
by Jim Fulton 15 Jan '06

15 Jan '06

The eggs quick guide http://peak.telecommunity.com/DevCenter/PythonEggs#using-eggs says that eggs can be installed by just putting them on sys.path. This doesn't seem to be enough though. A .pth file seem to also be necessary. Am I missing something? Or is the documentation incorrect? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

3 3

License for virtual-python.py?
by Jim Fulton 15 Jan '06

15 Jan '06

virtual-python.py looks very useful. It lacks a license/copyright statement though. Can we get this? Are there plans to include this script in 2.5? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

2 1

Dynamic linking on Linux, Mac OS, et al
by Phillip J. Eby 14 Jan '06

14 Jan '06

Hi folks. I just implemented preliminary shared library build support for setuptools, but I ran into a bit of a snag. I was operating under the assumption that you could simply put shared libraries in the directory alongside the extensions that use them, but in practice it turns out that this only works on Windows. On Linux I found that you could only put shared libraries in a directory on LD_LIBRARY_PATH, and I suspect a similar issue will be found under OS X and other Unixes. This seems to be a bit of a problem, in that it appears to mean there's no sane way to include shared libraries in an egg on any platform other than Windows. It's common practice for Python extensions built for Windows to include shared libraries to avoid having to install them in the Windows system directories, but for Unix-like OSes this isn't really the normal practice anyway. But, in the case where a developer wants to include a shared library as part of the distribution, this remains somewhat problematic. One can of course install the library to a platform-appropriate location ($prefix/lib on most platforms), but to do it from an egg is harder. You can't simply unzip the egg any more, you would have to also move the libraries to a standard installation location, breaking any hope of multi-version support. (And this would have to be able to happen on the fly, when shared libraries and extensions are extracted to the cache directory, if running zipped.) I don't suppose you can modify LD_LIBRARY_PATH on the fly? Any other options? Should I just give up on supporting shared libraries on anything but Windows, perhaps silently converting the shared libraries to static ones?

5 8

setuptools: branch versions
by Ian Bicking 13 Jan '06

13 Jan '06

One thing that would be nice, but seems rather substantial, would be a way to tag branches. Right now 0.1dev and 0.1wsgi are ordered in some way, and for branches I'd actually like for them not to be ordered -- you really want one tag or the other, and they aren't interchangeable in any way. Which maybe is possible now. Though the version specifiers make it hard too, because how do you say you want 0.1wsgi-*? Ultimately I'm looking for a "tag_svn_branch = true" setting, I guess, but the version sorting makes that less useful. -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

2 1

making easy_install install extras
by Andrew Straw 12 Jan '06

12 Jan '06

Hi, Is it possible to convince easy_install to grab extras specified in the "extras_require" arguments to setup()? I know this probably isn't something that should be on by default (that's why they're "extras"), but it would be nice to do something like: easy_install some_package --also-install-all-available-extras If it's not currently possible, I'd like to submit this as a feature request. Cheers! Andrew

2 4

man pages (& gzip & bdist_rpm on SuSE, oh my!)
by Charles Duffy 12 Jan '06

12 Jan '06

I'm trying to use bdist_rpm to build RPMs for a number of 3rd-party packages on SuSE SLES9. Among the issues I've run into: SuSE has a different %mandir from Red Hat -- man pages go under /usr/share/man rather than /usr/man. Upstream setup.py specifies data_files=[('man/man1', ['bzr.1'])]. I can change this to reference 'share/man/man1', which lets me build my package -- but it'd be nice to have something I can distribute upstream. Do I need to actually look at the filesystem and determine whether /usr/share/man exists and pass in the appropriate path, or is there a better approach? In /usr/lib/rpm/suse-macros, an __os_install_post macro is specified which calls %{suse_check} and then /usr/lib/rpm/brp-compress. Either of these will compress man pages (among other files), should it find them. This leads to the issue described in http://mail.python.org/pipermail/distutils-sig/2001-December/002674.html. Other than temporarily modifying /usr/lib/rpm/suse-macros, are there any ready workarounds? Thanks!

1 0

Re: [Distutils] Dynamic linking on Linux, Mac OS, et al
by Phillip J. Eby 11 Jan '06

11 Jan '06

At 02:11 PM 1/6/2006 +0800, Jeff Pitman wrote: >Unless you do something really magical, you're going to find a lot of >resistance to this in most Linux distro camps. Gentoo will want to >recompile via emerge. Fedora/CentOS will want to grab from yum. Debian >will want to grab libs via apt. The issue for the PyICU/PyLucene etc. use cases is that there are a whole bunch of SWIG wrappers for different extensions, but with a large common library for type mapping etc. The authors want a shared library for *their own code* that is used by multiple extensions. This is not separately distributed code. This is not the same thing as the Windows use case for building a shared library, although the ability to do it on Windows satisfies this use case too.

4 4

setuptools: confusion with non-egg installed packages
by Ian Bicking 11 Jan '06

11 Jan '06

I had a confusing installation experience today. Trac was installed in /usr/local/lib/python2.4/site-packages/trac, and I checked out a version that I had hacked to use setuptools, and run "python setup.py develop" on. This added my checkout to the path, but after site-packages, so it wouldn't be loaded, even if I did require('trac'). Now, if I did setup.py develop -m it would actually work, because setuptools would fix up the path correctly. I don't know the best resolution here. Maybe develop should check for conflicting installed packages? -- Ian Bicking | ianb(a)colorstudy.com | http://blog.ianbicking.org

2 1

Re: [Distutils] Dynamic linking on Linux, Mac OS, et al
by Phillip J. Eby 10 Jan '06

10 Jan '06

At 12:59 PM 1/7/2006 +0800, Jeff Pitman wrote: > If you need .so that's built and exported by the same packaged egg, you > may just consider installing it in a more benign area such as /usr/local/lib. As I mentioned before, this breaks multi-version support, although I suppose one could perhaps force the egg version to always be included in the filename... that would lead to some interesting problems as far as keeping the build area clean, though! You'd have to run a "clean --all" whenever the version number changed, and the extensions using the library would have to refer to the exact version. Unfortunately, this would *still* require users to mess with LD_LIBRARY_PATH in order to use private library versions, and so isn't particularly useful. Some variant of the "patch the extensions' runtime path at installation/cache extraction time" approach would still be necessary. There is actually a hook in pkg_resources whose purpose was to support doing this kind of thing with any code resources extracted to the egg cache, so it's probably doable, and I could probably also make the code usable by easy_install during egg unpacking. It pretty much means the "unzip the egg manually" concept is a dead duck when libraries are involved, though. You could only safely unpack an egg using a manually-created ResourceManager with an appropriate extraction path base. On Mac OS there's an option to automatically pad the rpath area, but on other OSes I'd need to do the padding myself by supplying an extra-long rpath entry that could then be overwritten during the extraction process. What bothers me about all of this is that moving an installed egg then *breaks* it, because the rpath is now hard-wired. Sigh. Ironically enough, an egg containing a shared library would then need to be labeled as "not unzip safe", i.e., it's really only safe to use if it remains zipped. A new category of egg, to be sure. :) Interestingly, this is one of the few times where I have to say that Windows is actually better-designed than Unix. Sure, the same design choice enables all other sorts of DLL hell, but on this very narrow specific issue Windows kicks ass. :) Anyway, I really wish there were a way to hook into the dynamic link process that didn't require one to manage the entire linkage one's self. The dl.open() function lets you get access to symbols, but that doesn't seem sufficient. :(

4 3