Mailman 3 April 2006 - Distutils-SIG

Package versioning
by Timothy Docker 29 Apr '18

29 Apr '18

Hi all, I've been aware that the distutils sig has been simmerring away, but until recently it has not been directly relevant to what I do. I like the look of the proposed api, but have one question. Will this support an installed system that has multiple versions of the same package installed simultaneously? If not, then this would seem to be a significant limitation, especially when dependencies between packages are considered. Assuming it does, then how will this be achieved? I am presently managing this with a messy arrangement of symlinks. A package is installed with its version number in it's name, and a separate directory is created for an application with links from the unversioned package name to the versioned one. Then I just set the pythonpath to this directory. A sample of what the directory looks like is shown below. I'm sure there is a better solution that this, and I'm not sure that this would work under windows anyway (does windows have symlinks?). So, has this SIG considered such versioning issues yet? Cheers, Tim -------------------------------------------------------------- Tim Docker timd(a)macquarie.com.au Quantative Applications Division Macquarie Bank -------------------------------------------------------------- qad16:qad $ ls -l lib/python/ total 110 drwxr-xr-x 2 mts mts 512 Nov 11 11:23 1.1 -r--r----- 1 root mts 45172 Sep 1 1998 cdrmodule_0_7_1.so drwxr-xr-x 2 mts mts 512 Sep 1 1998 chart_1_1 drwxr-xr-x 3 mts mts 512 Sep 1 1998 Fnorb_0_7_1 dr-xr-x--- 3 mts mts 512 Nov 11 11:21 Fnorb_0_8 drwxr-xr-x 3 mts mts 1536 Mar 3 12:45 mts_1_1 dr-xr-x--- 7 mts mts 512 Nov 11 11:22 OpenGL_1_5_1 dr-xr-x--- 2 mts mts 1024 Nov 11 11:23 PIL_0_3 drwxr-xr-x 3 mts mts 512 Sep 1 1998 Pmw_0_7 dr-xr-x--- 2 mts mts 512 Nov 11 11:21 v3d_1_1 qad16:qad $ ls -l lib/python/1.1 total 30 lrwxrwxrwx 1 root other 29 Apr 10 10:43 _glumodule.so -> ../OpenGL_1_5_1/_glumodule.so lrwxrwxrwx 1 root other 30 Apr 10 10:43 _glutmodule.so -> ../OpenGL_1_5_1/_glutmodule.so lrwxrwxrwx 1 root other 22 Apr 10 10:43 _imaging.so -> ../PIL_0_3/_imaging.so lrwxrwxrwx 1 root other 36 Apr 10 10:43 _opengl_nummodule.so -> ../OpenGL_1_5_1/_opengl_nummodule.so lrwxrwxrwx 1 root other 27 Apr 10 10:43 _tkinter.so -> ../OpenGL_1_5_1/_tkinter.so lrwxrwxrwx 1 mts mts 21 Apr 10 10:43 cdrmodule.so -> ../cdrmodule_0_7_1.so lrwxrwxrwx 1 mts mts 12 Apr 10 10:43 chart -> ../chart_1_1 lrwxrwxrwx 1 root other 12 Apr 10 10:43 Fnorb -> ../Fnorb_0_8 lrwxrwxrwx 1 mts mts 12 Apr 10 10:43 mts -> ../mts_1_1 lrwxrwxrwx 1 root other 15 Apr 10 10:43 OpenGL -> ../OpenGL_1_5_1 lrwxrwxrwx 1 root other 33 Apr 10 10:43 opengltrmodule.so -> ../OpenGL_1_5_1/opengltrmodule.so lrwxrwxrwx 1 root other 33 Apr 10 10:43 openglutil_num.so -> ../OpenGL_1_5_1/openglutil_num.so lrwxrwxrwx 1 root other 10 Apr 10 10:43 PIL -> ../PIL_0_3 lrwxrwxrwx 1 mts mts 10 Apr 10 10:43 Pmw -> ../Pmw_0_7 lrwxrwxrwx 1 root other 10 Apr 10 10:43 v3d -> ../v3d_1_1

3 2

[Distutils-sig] distutils charter and interscript
by John Skaller 29 Apr '18

29 Apr '18

3 2

setuptools site-package pollution
by Anthony Tarlano 10 Oct '06

10 Oct '06

Hi all.. Firstly, I would like to say thanks for the setuptools package, which I was introduced to after reading about the RuleDispatch package on the IBM developerworks charming python series. Oh btw. RuleDispatch is the most useful python package that I have seen in the last year in the python world, so thanks for that also ;) Now that the congrats and hugs are out of the way, I would like to ask a question. How can I tell setuptools not to put packages, such as dispatch, protocols, and setuptools, in a subdirectory named the same as the egg and to just put the package name. For example from pydoc I currently get: c:\python\lib\site-packages\ruledispatch-0.5a0.dev_r2100-py2.4-win32.egg dispatch (package) c:\python\lib\site-packages\pyprotocols-1.0a0dev_r2082-py2.4-win32.egg dispatch protocols (package) c:\python\lib\site-packages\setuptools-0.6a8-py2.4.egg easy_install pkg_resources setuptools (package) site what I would like to see is just: ..\site-packages dispatch (package) ..\site-packages protocols (package) ..\site-packages setuptools (package) Maybe it is just a pet-peeve, but I like to keep a nice tidy site-packages directory, and these long directory names just seem to me to be pollution of my site-packages directory in my command shell. If there is an option to have just the packages, I would really appreciate someone telling me what it is. If not maybe it could be considered, and to put whatever meta-data the directory names are providing somewhere else.. Thanks, Anthony

3 2

Re: [Distutils] easy_install question
by Phillip J. Eby 27 Apr '06

27 Apr '06

At 06:47 PM 4/27/2006 -0400, Collin Winter wrote: >On 4/27/06, Phillip J. Eby <pje(a)telecommunity.com> wrote: > > The problem is that you've uploaded distributions for two different > > projects: one named "functional-C", and the other named > > "functional-Py". Since neither one is "functional", EasyInstall keeps > looking. > >Would EasyInstall prefer names like functional-0.6-Py* instead? Technically, that would be a version number: "0.6-Py", and it would mean the "Py post-release of version 0.6". "0.6-C", on the other hand, would mean a "release candidate of version 0.6". >Even with the name change, though, my real question remains: how would >EasyInstall decide between, say, functional-0.6-Py.tar.gz and >functional-0.6-C.tar.gz (or similarly-named eggs)? By the higher version number, which in this case would be 0.6-Py. There are two ways you can solve this problem: 1. Name the projects functional-C and functional-Py, and give each its own Cheeseshop listing (ala ElementTree/cElementTree), or 2. Do a source-only distribution that builds the C extension if and only if a C compiler is available. Call the single project "functional". #2 is hard to do at the moment, as neither the distutils nor setuptools support such a fallback position at present. I hope to add some kind of "this C extension is optional" support during the 0.7 development cycle.

1 0

Re: [Distutils] easy_install question
by Phillip J. Eby 27 Apr '06

27 Apr '06

At 05:09 PM 4/27/2006 -0400, Collin Winter wrote: >I've been testing the latest release of my functional package[1] to >see that it works with easy_install. When I do "easy_install >functional", it shows that it looks at PyPI, can't find anything >appropriate, then goes on to the project's website, eventually >downloading and installing functional-Py-0.6.tar.gz. > >I imagine that easy_install is getting confused by the seven files >listed on the PyPI page; there are two versions of the package -- one >in C and one in pure Python -- with tarballs and eggs for each >version. Is there any way that I can mark a particular file (in an >easy_install-understandable way) as, "if you don't know what you need, >download this"? Should I use the "Download URL" field for this? The problem is that you've uploaded distributions for two different projects: one named "functional-C", and the other named "functional-Py". Since neither one is "functional", EasyInstall keeps looking.

2 1

easy_install question
by Collin Winter 27 Apr '06

27 Apr '06

I've been testing the latest release of my functional package[1] to see that it works with easy_install. When I do "easy_install functional", it shows that it looks at PyPI, can't find anything appropriate, then goes on to the project's website, eventually downloading and installing functional-Py-0.6.tar.gz. I imagine that easy_install is getting confused by the seven files listed on the PyPI page; there are two versions of the package -- one in C and one in pure Python -- with tarballs and eggs for each version. Is there any way that I can mark a particular file (in an easy_install-understandable way) as, "if you don't know what you need, download this"? Should I use the "Download URL" field for this? Thanks, Collin Winter [1] - http://cheeseshop.python.org/pypi/functional

1 0

Bug in parsing entry points with extras spec?
by Christopher Lenz 27 Apr '06

27 Apr '06

Hi all, I'm trying to specify an extra for an entry point, as follows: setup( ... extras_require = { 'DNS': ['dnspython>=1.3.5'] }, entry_points = { 'trac.plugins': [ 'spamfilter = tracspamfilter.api', 'spamfilter.adapters = tracspamfilter.adapters', 'spamfilter.filters.akismet = tracspamfilter.filters.akismet', 'spamfilter.filters.ip_blacklist = tracspamfilter.filters.ip_blacklist [DNS]' ] }, ... ) egg_info then fails with the message: ValueError: ('Invalid module name', 'tracspamfilter.filters.ip_blacklist ') Obviously the space between the module and the extras spec is messing up the parsing somehow, so I remove the space. Now, this works *only the first time* (i.e. before the entry_points.txt file) gets written out. Apparently setuptools also puts a space between the module name and the extras :-P Using setuptools 0.6a10... couldn't find anything related in the check-in messages. Am I missing something obvious here? Or isn't anyone actually using that particular feature yet? Anyway, replacing "value.lstrip()" with "value.strip()" in EntryPoint.parse() appears to fix this. Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/

3 3

Create 'bdist' installer from already-compiled SWIG DLL/SO
by John Pye 27 Apr '06

27 Apr '06

Hi all, I have a C++ library that I recently wrapped to allow it it be used from Python. I have used SCons as my build tool, and I want to continue using that. Now that I have completed my python language bindings, I want to work out a sensible way to create an installable version of this code. I want to use the python 'distutils' as that seems to be preferable (in the case of Python programs) to using something like NSIS. How can I use distutils to package up an *already-built* wrapper .py and .dll file? I don't have any other files that I need to distribute. Everything in the distutils documentation assumes that you will use Python to compile from sources. But the SWIG support in distutils is not complete enough (and anyway, I want to use SCons for the compiling stage). Here is my current effort, but it doesn't handle the 'dll' correctly (and isn't cross-platform, but that's OK): #!/usr/bin/env python from distutils.core import setup, Extension setup(name='freesteam' , version='0.6' , py_modules=['freesteam'] , ext_modules=[Extension('_freesteam',['_freesteam.dll'])] ) Any suggestions would be great. Cheers JP -- John Pye Department of Mechanical and Manufacturing Engineering University of New South Wales, Sydney, Australia http://pye.dyndns.org/

1 0

Setuptools / Python2.5 status ?
by Philippe Normand 26 Apr '06

26 Apr '06

Hi, I've read in PEP 356 that setuptools in the completed features list of Python2.5. Then i've read a mail from Phillip telling setuptools in now in Python trunk : http://mail.python.org/pipermail/distutils-sig/2006-April/006240.html But PEP 356 mentions that bdist_egg won't be part of Python2.5, so i'm a bit confused. If i want to distribute software using Eggs for Python2.5, do the final user or admin still needs to install setuptools himself ? If bdist_egg wouldn't be part of Python2.5, it would be impossible for developers to build Eggs, is that right ? So he'd still need to install setuptools yet ? Ok there are usefull scripts like working-env or virtual-python, but i apprehend them better in the developer context than from the final user point of view. So i'd like to be sure that requiring Python2.5 for the final user would make both final user and developer happy ;-) BTW this is probably off-topic, but does anybody has news about alpha2 ? PEP 356 says it should have been released yesterday and i've seen nothing so far. Philippe

2 1

setuptools, PYTHONPATH and suExec
by Joe Gregorio 26 Apr '06

26 Apr '06

I recently installed 'paste' via setuptools to a local directory. I don't have root on this system so I had to use the --prefix option. From the command line everything works fine: $ python Python 2.4 (#1, May 19 2005, 08:18:31) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-49)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import paste >>> But when I try to import paste from a .CGI script it fails. The problem seems to be PYTHONPATH, or the lack-there-of. I have a PYTHONPATH in my shell and that seems to be the reason paste works from the shell. In the .CGI script I don't have PYTHONPATH and the import of paste fails. I tried manipulating sys.path at runtime from within the CGI, but I believe that is too late and by the time my script starts running the wrong (non- PYTHONPATH) site.py has already been read. I tried adding PYTHONPATH to the environment by adding SetEnv PYTHONPATH /blah to the .htaccess, but I am running under suExec which appears to only pass in white-listed environment variables. Is there a way to get this to work or am I out of luck? Thanks, -joe -- Joe Gregorio http://bitworking.org

3 3