Mailman 3 October 2007 - Distutils-SIG

Bugfix for hg.setuptools
by Yannick Gingras 05 Oct '07

05 Oct '07

The Mercurial plugin for Setuptools available here: http://cheeseshop.python.org/pypi/hg.setuptools/ will render setuptool unusable outside of a Mercurial repository. Here is a patch to solve the problem: http://ygingras.net/files/hg.setuptools-without-a-repo.diff and a patched release: http://ygingras.net/files/hg.setuptools-0.1.1.tar.gz http://ygingras.net/files/hg.setuptools-0.1.1.zip http://ygingras.net/files/hg.setuptools-0.1.1-py2.4.egg http://ygingras.net/files/hg.setuptools-0.1.1-py2.5.egg I submitted the patch to the maintainer but I'm still without news from him. I hope this will help anyone who wants to use the plugin before an official bugfix release is out. -- Yannick Gingras

1 0

extending setuptools to use other revision control tools for --tag-svn-revision ?
by zooko 04 Oct '07

04 Oct '07

Folks: The allmydata.org tahoe project uses setuptools and the darcs revision control tool [1]. We've long since written a custom script to generate the version number from the revision control history. With this we can update our release version number in exactly one place -- the revision control tool -- and the script produces the Python module's __version__ attribute as well as the setup.py's "version" argument. The script also produces the equivalent of "revision numbers" (which in darcs is the count of patches that have been applied since the last release tag). You can see the details here: [2, 3, 4, 5]. The question is: is there a way to extend setuptools to do something like this for revision control tools other than svn? Thank you for your time. Regards, Zooko [1] http://darcs.net [2] http://allmydata.org/trac/tahoe/browser/misc/make-version.py [3] http://allmydata.org/trac/tahoe/browser/src/allmydata/__init__.py [4] http://allmydata.org/trac/tahoe/browser/setup.py [5] http://allmydata.org/trac/tahoe/browser/Makefile

1 0

setuptools darcs plugin
by Zooko O'Whielacronx At Work 04 Oct '07

04 Oct '07

Folks: If you use the darcs revision control tool [1], then you might like the setuptools darcs plugin [2] that I just wrote, which makes it so that setuptools by default includes all of your revision-controlled files in the tarballs it produces. This makes setuptools treat darcs the same way that it currently treats, I think, svn and cvs. There are also comparable setuptools plugins for bzr [3] and monotone [4]. Regards, Zooko [1] http://darcs.net [2] http://pypi.python.org/pypi/setuptools_darcs_plugin [3] http://pypi.python.org/pypi/setuptoolsbzr [4] http://pypi.python.org/pypi/setuptools_mtn

1 0

Distutils ignoring INSTALL_SCHEMES (or: How to put data files in PURELIB)
by Alexandre Gauthier 03 Oct '07

03 Oct '07

Hello there. I'm currently trying to package python bindings for a library. The bindings are currently compiled in an obscure way, so I end up with the following libmylib\__init__.py libmylib\mylib.pyd libmylib\dep.dll mylib.py Where mylib.py is the SWIG interface for mylib.pyd. Since I cannot have distutils compile the bindings at all, I'd like to just install the pyd and dll as "data files" along with the .py in "site-packages". That can be accomplished with the following: for scheme in INSTALL_SCHEMES.values(): scheme['data'] = scheme['purelib'] However, bdist_wininst will actually ignore this, at least in python 2.5.1. I'll end up with the pyd and dll in the DATA dir, instead of in the PURELIB one. I'm really at loss on how to proceed. I read about forcing /PURELIB/ in front of file paths with the following: if sys.argv[1] == 'bdist_wininst': for fileInfo in COMPILED_LIBS: fileInfo[0] = '/PURELIB/%s' % fileInfo[0] However, that doesn't work, and complains the path for each file forced into PURELIB this way can't be absolute. I also tried installing the file into an absolute path constructed from sys.path variables, which actually worked if I ran "setup.py install", but creating a bdist_wininst with that setup file actually just ignored the files to copy. I'm really at loss on how to proceed. The setup file doesn't need to be cross platform. It just needs to be able to build a friendly windows installer -- that's all... If anyone could help, i'd be immensely grateful. Thank you. -- Alexandre Gauthier

2 5

namespace package doesn't get its __init__.py file if --single-version-externally-managed
by zooko 02 Oct '07

02 Oct '07

The full version is here: https://bugs.launchpad.net/zope3/+bug/146373 The short version is that if you run ./setup.py install --single- version-externally-managed from the zope.interface 3.4.0 source tree, you'll get everything you need to import zope.interface except for the "zope/__init__.py" file. Is this a bug in setuptools? Regards, Zooko

2 1

ANN: z3c.recipe.egg - Recipes based on zc.recipe.egg for working with source distributions
by Ross Patterson 01 Oct '07

01 Oct '07

I just bundled up and released some zc.buildout recipes I've found useful. Attached is the README.txt. http://cheeseshop.python.org/pypi/z3c.recipe.egg Ross ============== z3c.recipe.egg ============== Recipes based on zc.recipe.egg for working with source distributions. Editable Distributions ---------------------- The z3c.recipe.egg:editable recipe uses the easy_install --editable and --build-directory options to download multiple source distributions. The source distributions will be placed in the part directory and managed by the buildout if build-directory is not specified. If so, the distributions will be replaced when newer versions are available. So be sure to set build-directory to a directory not managed by buildout if you want to maintain changes to the source distributions. The z3c.recipe.egg:editable can be used to assemble a set of subversion checkouts to work with specifying subversion URLs in find-links as is supported by easy_install. See the easy_install documentation for the syntax for using subversion URLs. There are a number of ways in which it is more flexible to control checkouts via recipes rather than svn:externals. Finally, if the develop option is true then the distributions will be installed in develop mode. See z3c/recipe/egg/editable.txt for more details. Running Setup Scripts --------------------- The z3c.recipe.egg:setup recipe calls arbitrary setup.py commands on multiple distributions in a buildout. The z3c.recipe.egg:setup recipe can be used, for example, to automate releases. When the source is ready for release, the setup recipe is configured to run the "register sdist bdist_egg upload" setup commands. To ensure release only runs when intended, the setup recipe can be used in it's own release.cfg file that extends the buildout.cfg file. With this setup, releases for multiple projects can be made with "bin/buildout -c release.cfg". The z3c.recipe.egg:setup recipe also supports the develop option as with z3c.recipe.egg:editable. See z3c/recipe/egg/setup.txt for more details.

1 0

Problem with easy_install
by Christian Klinger 01 Oct '07

01 Oct '07

Hi, i hope this is the right mailing-list to ask for help. Something with my easy install goes wrong: svcwebkerb:/# easy_install virtualenv -v 'import site' failed; use -v for traceback Traceback (most recent call last): File "/usr/local/bin/easy_install", line 5, in ? from pkg_resources import load_entry_point ImportError: No module named pkg_resources Does anyone have an idea what to do. I tried update setuptools but with no luck. Christian

2 1

errors compiling c++ extensions with swig on windows
by Karl Kobata 01 Oct '07

01 Oct '07

Christian, Did you get a reply for your questions? If so, please forward or post. Thanks karl

2 1

mingw32 exe problem
by pkienzle 01 Oct '07

01 Oct '07

Summary: cannot create windows exe files with distutils and mingw gcc-4.2. The fix is to remove the def_file from the list of objects in the link line. When building my own version of py2exe with --compiler=mingw32, I was able to compile (with some hacking of the py2exe source) but could not create usable windows binaries. The error I got when trying to run them is, "myapp.exe is not a valid Win32 application". Laboriously tracing code and modifying the link line by hand, I found I could build usable EXEs if I eliminated the following line from cygwinccompiler.py: objects.append(def_file) The def file itself contains: LIBRARY run.exe EXPORTS I'm using the technology preview gcc-4.2.1-dw2 prerelease from the mingw download site. I don't know if the def file is required on the current release gcc-3.4.5. Let me know if this is considered a bug in distutils, or if I need to post this message to the mingw list. Thanks in advance - Paul -- View this message in context: http://www.nabble.com/mingw32-exe-problem-tf4546042.html#a12972801 Sent from the Python - distutils-sig mailing list archive at Nabble.com.

1 0