Mailman 3 November 2006 - Distutils-SIG

distutils extension and setuptools
by Samuel Dufour 29 Nov '06

29 Nov '06

Hi, We currently develop a software to integrate packages (C++/Python) in plant modeling. We use SCons to build C++ library and Boost.Python to create the wrappers. We have extended distutils to call scons rather than distutils.build_ext. Thus, we distribute packages with the distutils frontend (sdist, bdist_*). All python modules are installed in a common namespace (a meta-package). All libraries and data (shared libraries, headers, tests,...) are installed in a common directory on the system which is external to the python installation (e.g. /usr/local). We would like to use setuptools functionalities to manage dependencies between packages. Is it possible to extend setuptools as we extend distutils to deals correctly with external data ? Thanks. Samuel N.B.: Our own distutils extension (OpenAlea.DistX) provides the following subcommands: - build_scons : call scons with subprocess during the build process. - build_namespace : create meta packages (just a directory and a __init__.py). - install_external_data : copy some data in a custom place. We adapt sdist and bdist_* commands to manage this kind of data. It is like the 'data_file' field, but add recursive copy and the detection of base destination directory depending of the system configuration. - set_env_var : set windows environment variable to discover shared libs at runtime. OpenAlea.DistX is available on http://gforge.inria.fr/frs/?group_id=79&release_id=782

2 1

buildout WHUI heads up
by Jim Fulton 29 Nov '06

29 Nov '06

This is a heads up that I'm going to call "we haven't used it!" on a couple of buildout features. The next release of buildout will not support ConfigParser-style variable substitutions (e.g. %(foo)s). Only the string-template style of variable (e.g. ${section:option}) substitutions will be supported. Supporting both violates "there's only one way to do it". I'm deprecating the buildout-section extendedBy option. Ian suggested to me a while ago that this wasn't needed and I've come to agree with him. If anyone is using these features and will have pain by having them disappear, please let me know. It will be at least a couple of days, probably more, before I make a new release. 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

1 0

Organizing for buildout questions
by David Pratt 28 Nov '06

28 Nov '06

Hi. I am trying to get my head around using buildout with both private and public repositories. So my questions relate to a way to organize my svn in a better way for eggification and construction of a simple sandbox to keep my svn checkouts together in a consistent and portable way. The goal is to checkout sources, modifying and checking in my changes as I go, and having the buildouts in their own folders reflect the changing code and dependencies. My first couple of questions are whether buildout can use a folder as source for a (development) egg - something that will update, secondly whether an egg can be created with ssh to a private repository like: svn+ssh://myaccount@myrepo.example.com/usr/home/myaccount/svn/path /to/my/project I have been using ssh for private code sources. In a recent buildout I have been studying, I have seen this: find-links = http://download.zope.org/distribution/ I am also looking at a simple sandbox structure that could also make some sense ... development --+-- private-src (private checked out sources) | +-- public-src (external checked out sources) | +-- buildout (a container for my active buildouts) My source containers would just hold folders of checked out code I am currently working on. I plan on checking out my buildouts from svn to a buildout container so that I could have a few or more different buildouts going at a time (each being an app or just testing some things in their own environment) I am curious about folders as sources since sometimes I just want to try some code without a lot of hassle or committing it to a repository right away. I think it would be good to try it in a buildout. With the structure of my development folder I could use a relative link from a source folder as well. On the repository side, I have been looking at zope's repository more critically which is structured like this: container-->branch-->src-->namespace-->package or when more nesting needed: container-->branch-->src-->namespace-->second namespace-->package setup.py is always at the branch with __init__ for eggs within each namespace package. It seems a good model for eggification since many packages are setup for eggs in a way that is fairly transparent. This of course is a public repository with packages being registered in PyPI. For a private repository, I would like to checkout the code as eggs equally as well. Any recommendations would be appreciated since I am not looking to do this sort of housekeeping any more than once in a long while. I am hoping with input I can get it fairly right and flexible. It seems now is the time to do this to prepare for buildout style development and packaging. Many thanks. Regards, David

2 1

include files with C extensions
by Antoine Pitrou 27 Nov '06

27 Nov '06

Hi, I've got a small problem with the C extension feature. It happens when your C (or Pyrex) extension is spread across several C sources, and you have a custom .h file to make the glue. Say: setup( ... ext_modules = [ Extension('mycext', [ 'src/custom1.c', 'src/custom2.c', ], include_dirs=['src']), ] Let's say custom1.c and custom2.c both include src/custom.h. The problem is when you only change src/custom.h without changing one of the C files. Setuptools does not know that custom.h is part of the C extension code, thus "setup.py build" doesn't rebuild it. Even trying "setup.py clean build" does not result into an actual rebuild. Also, including "src/custom.h" into the extension file list does not work, setuptools complaining that it doesn't know about ".h" files. Is there a clean way to have setuptools do a rebuild when the .h file is changed? Thanks, Antoine.

2 2

Python and psyco
by Marcel Goncalves Viana Marins de Camargos 24 Nov '06

24 Nov '06

hi, l use python often and i would like to know if you are planning to integrate python with psyco. I need it for speedup. I wasn't able to install psyco on my computer. I use python 2.5. thanks, marcel goncalves

1 0

(no subject)
by Philippe Normand 22 Nov '06

22 Nov '06

Hi, When I run that on a fresh checkout of my project (no build/ dir): python setup.py install -O1 --skip-build --root tmp/ I get a nice tmp/usr/lib/python2.4/site-packages/mypackage.egg/ directory (zip_safe set to False in setup()). Then when I run : python setup.py build It creates a build/ directory as expected. Now if I run the first command again, the packages internal to the egg are installed directly in tmp/usr/lib/python2.4/site-packages/ ... Is this a bug or a feature? I reproduce it with 0.6c2 (on Fedora Core 6) and 0.6c3 (on Ubuntu Edgy) versions of setuptools. Philippe

2 5

[setuptools] setup.py install --skip-build --root "pollutes" site-packages
by Philippe Normand 21 Nov '06

21 Nov '06

Hi, When I run that on a fresh checkout of my project (no build/ dir): python setup.py install -O1 --skip-build --root tmp/ I get a nice tmp/usr/lib/python2.4/site-packages/mypackage.egg/ directory (zip_safe set to False in setup()). Then when I run : python setup.py build It creates a build/ directory as expected. Now if I run the first command again, the packages internal to the egg are installed directly in tmp/usr/lib/python2.4/site-packages/ ... Is this a bug or a feature? I reproduce it with 0.6c2 (on Fedora Core 6) and 0.6c3 (on Ubuntu Edgy) versions of setuptools. Philippe

1 0

Non-python machines
by Robert McFadzean 21 Nov '06

21 Nov '06

Is it possible to distribute a python module with Python to run on a machine that doesn't have Python or would Python have to be installed separately first? Robert G. McFadzean Instructor Vermilion School of Agriculture Lakeland College 5707 47 Ave West Vermilion AB T9X 1K5 Tlf: (780) 853-4890 Fax: (780) 853-8704 robert.mcfadzean(a)lakelandc.ab.ca

2 1

Re: [Distutils] SetupTools: The Case Of The Installed Egg
by Phillip J. Eby 21 Nov '06

21 Nov '06

At 12:41 PM 11/18/2006 -0500, Alexander Michael wrote: >It looks like SetupTools now attempts to lower case everything, but >doesn't in the case of an explicit install. Bug or feature? Neither; it's a meaningless quirk caused by the fact that easy_install doesn't case-normalize egg paths supplied via the command line. (Virtually everything else it does is with paths that are "absolutized" and case-normalized.) It doesn't cause any problems, if that's what you're wondering.

2 1

SetupTools: The Case Of The Installed Egg
by Alexander Michael 18 Nov '06

18 Nov '06

In setuptools-0.6c3-py2.4 on win32, installing an egg explicitly results in the installed egg directory having different case than installing it with a version requirement. The following example will explain it more clearly: $ C\:/Python24/Scripts/easy_install dist/Replicator-0.3-py2.4.egg Processing Replicator-0.3-py2.4.egg creating c:\python24\lib\site-packages\Replicator-0.3-py2.4.egg Extracting Replicator-0.3-py2.4.egg to c:\python24\lib\site-packages Adding Replicator 0.3 to easy-install.pth file Installed c:\python24\lib\site-packages\replicator-0.3-py2.4.egg Processing dependencies for Replicator==0.3 Make note of the "creating" message above and compare with the same below. $ C\:/Python24/Scripts/easy_install -f dist Replicator==0.3 Searching for Replicator==0.3 Best match: Replicator 0.3 Processing replicator-0.3-py2.4.egg creating c:\python24\lib\site-packages\replicator-0.3-py2.4.egg Extracting replicator-0.3-py2.4.egg to c:\python24\lib\site-packages Adding replicator 0.3 to easy-install.pth file Installed c:\python24\lib\site-packages\replicator-0.3-py2.4.egg Processing dependencies for Replicator==0.3 It looks like SetupTools now attempts to lower case everything, but doesn't in the case of an explicit install. Bug or feature? Thanks, Alex

1 0