Mailman 3 September 2005 - Distutils-SIG

Having problems with "scripts" section
by Scott Kirkwood 09 Sep '05

09 Sep '05

Ok, I give up. I'm using setuptools==0.5a13 and have the following problem. I'm trying (under Ubuntu Linux) to have my easy_install.py install a script to run my utility. However, it's unable to find the utility and I don't know why. The latest incarnation I changed the name of the script to runWx. Here's what happends when I run it: <distutils-sig(a)python.org> $ runWx Traceback (most recent call last): File "/usr/bin/runWx", line 4, in ? pkg_resources.run_script('wxOptParse==0.1.2', 'runWx') File "/usr/lib/python2.4/site-packages/setuptools-0.5a13-py2.4.egg/pkg_resources.py", line 111, in run_script require(dist_spec)[0].metadata.run_script(script_name, ns) File "/usr/lib/python2.4/site-packages/setuptools-0.5a13-py2.4.egg/pkg_resources.py", line 627, in run_script raise ResolutionError("No script named %r" % script_name) pkg_resources.ResolutionError: No script named 'runWx' it can't find runWx, ok, why not? here's the egg list: $ unzip -l dist/wxOptParse-0.1.2-py2.4.egg Archive: dist/wxOptParse-0.1.2-py2.4.egg Length Date Time Name -------- ---- ---- ---- 21025 09-08-05 12:54 wxoptparse/__init__.py 20091 09-08-05 22:26 wxoptparse/__init__.pyc 1315 09-08-05 22:26 EGG-INFO/PKG-INFO 11 09-08-05 22:26 EGG-INFO/top_level.txt 0 09-08-05 22:26 EGG-INFO/zip-safe 63 09-08-05 22:15 EGG-INFO/scripts/runWx -------- ------- 42505 6 files Here's the contents of /usr/bin/wxRun which appears to have been created: $ cat /usr/bin/runWx #!/usr/bin/python # EASY-INSTALL-SCRIPT: 'wxOptParse==0.1.2','runWx' import pkg_resources pkg_resources.run_script('wxOptParse==0.1.2', 'runWx') Contents of my original runWx #!python import wxoptparse wxoptparse.handleCommandLine() My setup.py file: from ez_setup import use_setuptools use_setuptools() from setuptools import setup, find_packages # Notes to self: # python setup.py sdist --formats=zip # To create the zip file # python setup.py --command-packages=setuptools.command bdist_egg # To create the egg file # python setup.py register # to register with PyPI # setup(name="wxOptParse", version="0.1.2", description="wxOptParse: run the command line options from a dialog box.", long_description="""\ wxOptParse is a Python program that brings up a graphical representation of the options that another python program has for the command line, via the optparse module. What this means is that if if you have a program that uses optparse you can click on checkboxes, edit boxes, combo boxes, etc. instead of using the command line. """, author="Scott Kirkwood", author_email="scottakirkwood(a)gmail.com", url="http://wxoptparse.berlios.de/", download_url=' http://developer.berlios.de/project/showfiles.php?group_id=2209&release_id=… ', packages=find_packages(exclude='tests'), scripts=["runWx"], keywords=['wxOptParse', 'optparse', 'python', 'wxPython'], license='GNU GPL', zip_safe=True, platforms=['POSIX', 'Windows', 'MacOS X'], classifiers=[ 'Development Status :: 3 - Alpha', 'Intended Audience :: End Users/Desktop', 'Intended Audience :: Developers', 'Intended Audience :: System Administrators', 'License :: OSI Approved :: GNU General Public License (GPL)', 'Operating System :: OS Independent', 'Operating System :: MacOS :: MacOS X', 'Operating System :: Microsoft :: Windows', 'Operating System :: POSIX', 'Programming Language :: Python', ], # package_data={'': '*.xml'}, # install_requires=['wxPython>=2.5.3'], # Doesn't work on my machine ) And my MANIFEST.in file: include setup.py include ez_setup.py include runWx include wxoptparse/runWx include README.txt include docs/*.css include docs/*.rst include docs/*.gif include docs/*.html include docs/*.png include wxoptparse/*.py Plus you can find all these files and more at http://developer.berlios.de/projects/wxoptparse/ Any help would be appreciated, this program won't be very useful if it's can't be run from the command line. -Scott

2 1

distutils questions
by Joachim Dahl 08 Sep '05

08 Sep '05

Hi, I have a regular setup script for an extension module using core.setup. Currently I have to manually run a make script to build the C object files, and then link them using the Python setup script. I would like to include the make file into the setup script, and I have been looking at how to tweak distutils, but I am quite in over my head here... My problem is that the C source files are compiled several times into different object depending on the preprocessor options, and thus I cannot simply include the source files into the "sources" list in the Extension module, e.g., as glpk = Extension('glpk', libraries = ['glpk'], include_dirs = [ GLPK_INC_DIR ], library_dirs = [ GLPK_LIB_DIR ], sources = ['C/glpk.c'] ) extmods += [glpk]; I need the setup script to build the module like this: gcc -Ddef1 -c foo.c -o foo_def1.o gcc -Ddef2 -c foo.c -o foo_def2.o gcc foo_def1.o foo_def2.o -o myext_module.o Is there currently a (relatively simple) way to include something like that into a distutils setup script, or is it easier to keep running a separate make file to build the different object files before linking? - Joachim

2 1

setuptools: Utility of setup() arguments
by Ian Bicking 06 Sep '05

06 Sep '05

I'm wondering, is there any reason to use the keyword arguments to setup() that write files to the .egg-info directory, instead of writing those files myself (assuming I was going to hardcode them in the Python source anyway). Specifically I'm coming back to some deployment stuff, and I'd like to make an installation process that installs all the dependencies using --multi-version, and then makes the deployed application require those exact versions -- this way nothing else on the machine should be effected by the installation. Doing this in an automated way seems reasonably straight-forward; read the requires.txt file, figure out what the versions are we installed just now (which might have build tags), and rewrite that file. I can rewrite that file easily, not so easy to rewrite setup.py. Relatedly, I'd prefer having entry_points.txt in my repository, since it's annoying when I forget to update it, or when I run "sudo python setup.py develop" it'll be written out as root, and I'll have to fix the permissions before rerunning "setup.py egg_info". Frankly I'd rather have PKG-INFO in the repository as a text file too, though it concerns me more that it is formed from several keyword arguments instead of one. So, to the degree this works (and I haven't tried it with PKG-INFO), is there any reason to use setup() arguments over editing the files it generates directly? -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

2 3

setuptools/EasyInstall 0.6a1 candidate 1 snapshot
by Phillip J. Eby 03 Sep '05

03 Sep '05

This thing's been in limbo too long, so I've made a prerelease snapshot. You can get it with: easy_install -f http://peak.telecommunity.com/snapshots/ setuptools I have fixed all reported bugs, and implemented quite a few new features like MD5 checking (which works even with PyPI's md5 data) and an enhanced "build_ext --inplace" that lets you switch between different Python interpreters without having to recompile your extensions. (The extensions are built in build/, then copied to the source tree whenever you "build_ext" using a different interpreter than the last.) If you have any projects using setuptools, I encourage you to give this snapshot a try, so I can find out if there are still any lurking bugs. If there are no bug reports by next weekend, this will get pushed out as 0.6a1. If you want to look at the documentation, use CVS or browse the EasyInstall.txt, setuptools.txt, and pkg_resources.txt files found at: http://cvs.sourceforge.net/viewcvs.py/python/python/nondist/sandbox/setupto… (I just made some changes to these, however, that may take a few hours to update in SourceForge's anonymous CVS.)

3 6

Fixing the stdlib
by Ian Bicking 02 Sep '05

02 Sep '05

Vaguely off-topic, but I figured someone here might know... Anyway, I want to provide backported stdlib modules to older versions of Python. Most of these are trivial to backport, so it's just a matter of accumulating them in one place. So I'm wondering how best I should put this in place. One way would be to import the backported modules, then modify sys.modules. But this requires importing everything ahead of time, which is no good. At the same time, I'd rather have the process Instantly Seem Upgraded (assuming the program isn't using any language features not supported by the process). I could actually distribute something that included the top-level modules; this would work for something like optparse or subprocess, where the module simply didn't exist before. But this doesn't work when providing updated modules that existed before but have been enhanced, like doctest. I'm also not sure when I should monkeypatch the existing module, or provide a new one. For instance, tempfile added a couple functions in 2.4, and UserDict added a useful class (DictMixin). Thoughts? -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

3 2