Mailman 3 November 2006 - Distutils-SIG

Why does build_ext accept -R but not build?
by Albert Chin 17 Nov '06

17 Nov '06

Why does "python setup.py build_ext" accept -R but "python setup.py build" does not? Isn't build a superset of build_ext? This is for Python 2.4.2. -- albert chin (china(a)thewrittenword.com)

2 1

Re: [Distutils] SetupTools: Running EasyInstall From Within A Script?
by Phillip J. Eby 17 Nov '06

17 Nov '06

At 12:42 PM 11/17/2006 -0500, Alexander Michael wrote: >I am attempting to put together a simple package installation >replicator to make it easier to pull updates from a local repository >(as an alternative setup to a shared NFS directory). The idea is to >put a requirements list and the necessary eggs in a local shared >directory and then have a script on each computer do a quick check to >see if any updates are needed and install them if there is an update. >Is it possible to ask setuptools to install a package from within a >Python script without resorting to os.system or friends? I tried >browsing the source, but it was difficult to follow the call chain >from the easy_install script to the actual method being called. The simplest way: from setuptools.command.easy_install import main main(['some', 'arguments', 'here'])

1 0

SetupTools: Running EasyInstall From Within A Script?
by Alexander Michael 17 Nov '06

17 Nov '06

I am attempting to put together a simple package installation replicator to make it easier to pull updates from a local repository (as an alternative setup to a shared NFS directory). The idea is to put a requirements list and the necessary eggs in a local shared directory and then have a script on each computer do a quick check to see if any updates are needed and install them if there is an update. Is it possible to ask setuptools to install a package from within a Python script without resorting to os.system or friends? I tried browsing the source, but it was difficult to follow the call chain from the easy_install script to the actual method being called. Thanks, Alex

2 1

easy_install and Unix python with sys.prefix different from sys.exec_prefix
by Berthold Höllmann 16 Nov '06

16 Nov '06

Hello, In our python installation python modules are shared between a Solaris, Linux and Linux-x86_64 installation. We are managing this by giving the --exec-prefix option as well as the --prefix option when configuring python and sharing the directories by NFS. This generally well with distutils, which put extensions under the --exec-prefix path and modules under the --prefix path. The problem with distutils are extensions expecting 'pyconfig.h' at os.path.join(sys.prefix,'install') and shebang string in scripts pointing to a python executable that works only for one architecture. For the shebang string problem it would be helpful to be able to set the default string to #! /usr/bin/env python" in a configuration file. With easy install there is a further problem. It installs extensions into os.path.join(sys.prefix,'lib','python-2.4','site-packages') instead of os.path.join(sys.exec_prefix,'lib','python-2.4','site-packages') which is a problem with the 'easy-install.pth' that point to an architecture sensitive egg in an directory shared by all architectures. Is there a way to fix these problems? Thanks Berthold -- __ Address: G / \ L Germanischer Lloyd phone: +49-40-36149-7374 -+----+- Vorsetzen 35 P.O.Box 111606 fax : +49-40-36149-7320 \__/ D-20459 Hamburg D-20416 Hamburg

2 6

sardonic
by Mercy Mejia 16 Nov '06

16 Nov '06

1 0

Sourceforge finally fixed???
by Phillip J. Eby 14 Nov '06

14 Nov '06

I just noticed today that Sourceforge now appears to have a sane download system in place, at long last! Download URLs now point to downloads.sourceforge.net instead of prdownloads, and they automatically select a mirror and redirect to it. If the mirror doesn't have the file, it redirects *back* to downloads.sf.net with a failed_mirror=mirror_name, so that the redirector can pick another mirror. So, in essence, the Sourceforge folks have automated easy_install's mirror selection and retry facility, which means that the code for doing that can possibly be dropped from future versions of easy_install. The new download system appears to be intended to support easier end-user downloads as well as automated downloads, so my guess is that the feature is here to stay. So, I plan to back out my experimental "heroic measures" code (using 'sf-mirrors.telecommunity.com' to get mirror IPs to try), leaving the older prdownloads support in place for the time being. Fortunately, the newer code is only in the 0.6c4 trunk, and not in any officially released version, so the experimental DNS mirroring will not be supported in the 0.6c4 final release, allowing me to drop that (automatically generated) zone from my DNS. Yay!

1 0

Re: [Distutils] should I use distutils for a gnome-applet?
by Phillip J. Eby 14 Nov '06

14 Nov '06

At 01:53 AM 11/10/2006 +0000, Jorge Vargas wrote: >so my question is will I really win from hoping over to distutils or >should I just stick with my Makefile? Stick with your Makefile and system packaging tools. Distutils is really only a win for Python *libraries*, not applications.

6 7

zc.buildout vr make Was: should I use distutils for a gnome-applet?
by Jorge Vargas 14 Nov '06

14 Nov '06

On 11/13/06, Eric S. Johansson <esj(a)harvee.org> wrote: this just got a bit out of topic > Jim Fulton wrote: > > zc.buildout's main improvement over > > make is the use of Python as it's scripting language. > > speaking as someone who has detested make from the minute I encountered > itsome 30 years ago, I think this is a big improvement. same here although I have to say I have much less years alive :) it gets really nasty went you get into the autotools stuff I believe for my needs I'll try to get my hand made Makefile don't get too complicated and don't go agains the flow with the gnome people > But it also > makes me wonder why didn't you use scons? It seems like it does > everything make it does only in a more easily understood way and has an > established user base. > I'm interested in that too, I was considering scons as a alternative for a bigger project of mine, any specific reasons why you left it out > for me the main resistance to using scons is that bumpy case words are > significant accessibility impediment. For example, how would you > pronounce "Build" and "build"? For most people they sound exactly the > same. To differentiate requires a lot of additional noise either spoken > or heard. > > ---eric > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG(a)python.org > http://mail.python.org/mailman/listinfo/distutils-sig >

2 1

main script problem
by Flavio Codeco Coelho 12 Nov '06

12 Nov '06

Hi, I am having a problem with the fact that setuptools copies the application main script to a different directory during installation. My application is a single package one where the mains script resides within the package. This script imports many of the other modules locally (i.e., import x, y, z) without having to refer to the package. So when the script is copied to /usr/bin, it no longer runs because it cannot import the other modules since they do not reside in the same diretory anymore. This would be a non-issue if setuptools made a simbolic link of the script to /usr/bin instead of copying it. Is there a way of forcing this? any other suggestions are welcome, Flávio

2 1

selecting compiler for bdist_rpm
by nmichaud＠jhu.edu 11 Nov '06

11 Nov '06

Hello, I am trying to compile a module with the Intel compiler, and I can't figure out how to get the bdist_rpm to change the default compiler. I can use build: python setup.py build --compiler=intel but for some reason it doesn't work for bdist_rpm: python setup.py bdist_rpm --compiler=intel gives me error: option --compiler not recognized How can I set the compiler (and CC won't work, because that doesn't set the default linker to use Intel's linker - and then I get all sorts of undefined _intel_memset errors when loading the module). Thanks. Naveen --------------------------------------------------------------------- Naveen Michaud-Agrawal Program in Molecular Biophysics Johns Hopkins University (410) 614 4435

2 1