Mailman 3 July 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

eggs and Python Unicode variants (UCS2, UCS4)
by Martijn Faassen 29 May '09

29 May '09

Hi there, In the lxml project (http://codespeak.net/lxml), we've just noticed the following problem with lxml eggs: you can easy_install an egg that won't work for your Python. This is because Python can be compiled with either 2 or 4 bytes unicode as its internal representation. Any egg that contains compiled C code that uses unicode such as lxml will run into trouble: if it's compiled with a 4 bytes unicode Python, it won't work on a 2 bytes unicode Python, and vice versa. This problem is fairly common in Linux. Many distributions such as Ubuntu and Fedora compile their python with 4 bytes unicode internal representation. If you compile a Python interpreter by hand it defaults to 2 bytes unicode, however. Hand-building a Python interpreter is done fairly commonly by Linux sysadmins for various reasons. It would therefore be very nice if it became possible to make eggs for the different unicode compilation options of Python. This configuration dimension is a real world issue for any binary Python module that does anything with unicode text.. In an earlier mail to this list: http://mail.python.org/pipermail/distutils-sig/2005-October/005222.html M.-A. Lemburg and Phillip Eby had the following discussion: [MAL] >>Please make sure that your eggs catch all possible >>Python binary build dimensions: >> >>* Python version >>* Python Unicode variant (UCS2, UCS4) >>* OS name >>* OS version >>* Platform architecture (e.g. 32-bit vs. 64-bit) [PJE] >As far as I know, all of this except the Unicode variant is captured in >distutils' get_platform(). And if it's not, it should be, since it >affects any other kind of bdist mechanism. I'm not sure whether this means this needs to be escalated from setuptools to the Python interpreter level itself. With this mail, I've done the job escalating this lxml problem to what appears to be the right place, though. :) Thanks, Martijn

5 5

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] python version information in .egg-info directory name
by Phillip J. Eby 01 Aug '06

01 Aug '06

At 06:49 PM 7/3/2006 +0200, Matthias Klose wrote: >Phillip J. Eby writes: > > At 10:28 PM 6/9/2006 +0200, Matthias Klose wrote: > > >Phillip J. Eby writes: > > > > At 09:51 PM 6/9/2006 +0200, Matthias Klose wrote: > > > > >Hi, > > > > > > > > > >when installing an egg in a system-installed python version, then you > > > > >do have another python version information in the egg_info directory > > > > >name (py2.x). Is it possible or advisable to exclude that information > > > > >from the name? At least I know that I'm installing into > > > > >/usr/lib/python2.3/site-packages. > > > > > > > > I don't understand your question. There is no 'egg_info' > directory. Are > > > > you talking about a .egg/EGG-INFO directory or an '.egg-info' > directory? > > > > > >sorry, > > > > > > /usr/lib/python2.3/site-packages/setuptools-0.6b2-py2.3.egg-info > > > > > >would it be safe to rename that to > > > > > > /usr/lib/python2.3/site-packages/setuptools-0.6b2.egg-info > > > > > >without loosing functionality? > > > > Yes. > >what about installing the .egg-info directory without version >information when --single-version-externally-managed is used? Note that the .pyc files will be built for a specific Python version; that's why the version number is there. Not including the version number won't magically make it work with other Python versions. >Another unrelated thing: Debian is supposed to ship the source code >for binaries, but it's not included in the package for cli.exe and >gui.exe. Could you point me to the source code and/or include it in >the next release? It's included in the source release, along with all the documentation. The file you're looking for is 'launcher.c'. Of course, the .exe files aren't used on non-Windows platforms anyway.

5 12

module_path, recursive scanning for (.pth) files does not work
by fredaa elder 31 Jul '06

31 Jul '06

Hi I have a problem (possible bug?) with the search path setup: version python 2.4.3 located in c:\python I want to have my modules in a completely separate dir: f:\dev\python\lib i made a test module f:\dev\python\lib\math\test_module.py now i have a test file in f:\dev\python\lib\test\test_001.py which needs to load test_module.py manual text: Installing Python Modules /Greg Ward Python Software Foundation Email: distutils-sig(a)python.org Release 2.4.3 29 March 2006 says: The most convenient way is to add a path configuration file to a directory that's already on Python's path, usually to the .../site-packages/ directory. Path configuration files have an extension of .pth, and each line must contain a single path that will be appended to sys.path. (Because the new paths are appended to sys.path, modules in the added directories will not override standard modules. This means you can't use this mechanism for installing fixed versions of standard modules.) Paths can be absolute or relative, in which case they're relative to the directory containing the .pth file. Any directories added to the search path will be scanned in turn for .pth files So: I put a file "lib.pth" in ../site-packages/ If I put the full path (f:\dev\python\lib\math) to test_module in this file, it works and test_001.py can load the test_module Now for the problem If i put only (f:\dev\python\lib) in lib.pth and I put a file math.pth in this path with a relative dir (math) sys.path will only have (f:\dev\python\lib) added to it and test_001.py cannot load the test_module conclusion: the "Any directories added to the search path will be scanned in turn for .pth files" does not work any suggestions? what did i do wrong? hope you can point me the way and thanks for a great language Frederik AA de Jonge __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

A question about installing Distutils
by Sergei Emantayev 30 Jul '06

30 Jul '06

Hello, I'm trying to install the Distutils libarary since it does not included in my python installation. I run Suse linux. I have python 2.4. I've downloaded the distutils version 1.0.2 (the latest one). When I run 'python setup.pyinstall' from the installation directory, I get the following error: Traceback (most recent call last): File "setup.py", line 30, in ? packages = ['distutils', 'distutils.command'], File "/home/semantay/Distutils-1.0.2/distutils/core.py", line 101, in setup _setup_distribution = dist = klass(attrs) File "/home/semantay/Distutils-1.0.2/distutils/dist.py", line 130, in __init__ setattr(self, method_name, getattr(self.metadata, method_name)) AttributeError: DistributionMetadata instance has no attribute 'get___doc__' Please help me. Sergey

2 2

unusual platform-dependent problem with tarfile created by setuptools
by Michael Bayer 29 Jul '06

29 Jul '06

hey all - the MyghtyUtils package, version 0.52 on cheeseshop, has this general file structure: MyghtyUtils-0.52/setup.py MyghtyUtils-0.52/ez_setup.py MyghtyUtils-0.52/lib/myghtyutils/__init__.py MyghtyUtils-0.52/lib/myghtyutils/memcached.py MyghtyUtils-0.52/lib/myghtyutils/<other .py files> MyghtyUtils-0.52/test/Container.py MyghtyUtils-0.52/test/LRUCache.py MyghtyUtils-0.52/test/SyncDict.py MyghtyUtils-0.52/test/testbase.py however, when you run "python setup.py sdist" on an OS X machine (interestingly, *not* on a windows machine), the resulting tar/gz file contains an extra file: MyghtyUtils-0.52/test/._Container.py no idea why that is...but this creates problems on windows. Then, when you go to install this package on a windows machine (*not* on an OS X or other unixy machine), you get this error: File "c:\python24\lib\site-packages\setuptools-0.6c1-py2.4.egg\setuptools \archive_util.py", line 192, in unpack_tarfile tarobj._extract_member(member,dst) # XXX Ugh File "C:\Python24\lib\tarfile.py", line 1440, in _extract_member self.utime(tarinfo, targetpath) File "C:\Python24\lib\tarfile.py", line 1572, in utime raise ExtractError, "could not change modification time" tarfile.ExtractError: could not change modification time when I go into tarfile.py line 1572 and modify the exception to also print out the underying error, you get this: IOError: [Errno 13] Permission Denied: 'MyghtyUtils-0.52\\test\ \._Container.py' So the extra "._Container.py" file is the source of the windows issue. If you want to reproduce, simply check out the latest source of MyghtyUtils from http://svn.myghty.org/myghtyutils/trunk and run "setup.py sdist". I havent seen this happen with my other packages. I have solved the problem by just running the sdist on the windows machine. but this is pretty strange. any ideas ?

2 4

Re: [Distutils] a patch for distutils + gcc + linux, that was never apply, yet will solve many problems.
by Jorge Vargas 24 Jul '06

24 Jul '06

sorry for not replying earlier I have been busy at work. On 7/14/06, Ronald Oussoren <ronaldoussoren(a)mac.com> wrote: > > > On Jul 14, 2006, at 3:35 PM, Jorge Vargas wrote: > > > On 7/11/06, Ronald Oussoren <ronaldoussoren(a)mac.com> wrote: > > > > On Jul 11, 2006, at 5:17 PM, Jorge Vargas wrote: > > > > > noone cares about this? it's a bug so simple to fix.... > > > > There's loads of bugs and patches in the python tracker, and only a > > limited amount of time that people work on python. The patch you > > mentioned also sounds like a fix for a very limited audience, which > > could explain why nobody has seriously looked at it yet. > > > > the patch is more then a year old and is so simple yet so usefull > > it will take less then 10 min for someone that has commit access > > I haven't looked at the actual patch yet, just read its description. > Given its description this patch is not something I would have > reviewed because it seems to be for a very limited audience and is > not something I can test without additional work (e.g. installing > ccache). If you open the patch it's just adding one flag to gcc > > > Are there systems other then gentoo that don't use gcc and g++ but > > some seemingly cross-compiling setup? > > > > the patch is directed to the unixcompiler so why cross-compile? > > Your example mentions a gcc that is named i686-pc-linux-gnu-gcc, > which looks like a cross-compiling setup to me, a conventional gcc > setup just has 'gcc' as the name of the compiler. Which systems > install gcc as i686-pc-linux-gnu-gcc? the system is gentoo the reason for ccache is that gentoo is a source based distro. As for the name it is just how the package system (emerge) calls it, although it will let you compile for other archs, the defaults are set to your system at instalation time. gcc -v Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/specs Configured with: /var/tmp/portage/gcc-3.3.6/work/gcc-3.3.6/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3.6 --includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3.6 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3.6/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3.6/info --with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/include/g++-v3 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --disable-multilib --disable-libgcj --enable-languages=c,c++,f77 --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8) Ronald > >

1 0

setuptools 0.6b4 released
by Phillip J. Eby 21 Jul '06

21 Jul '06

I have just released version 0.6b4 of setuptools, the last beta release of setuptools 0.6. Please upgrade and test at your earliest convenience, as I would like to issue a release candidate version next week. Changes include numerous bug fixes and tweaks for corner cases in easy_install processing, mostly discovered by Jim Fulton in the process of developing his "zc.buildout" tool (a Make-like system that supports simple installation of complex environments). In addition, there is now a formally-documented "package index API" that easy_install supports: http://peak.telecommunity.com/DevCenter/EasyInstall#package-index-api So, people who wish to create their own "package indexes" for easy_install can do so, even using static HTML -- even without a web server. Last, but not least, the ability was added to turn off SVN revision numbers or dates from the command line, so that you don't have to edit setup.cfg in order to issue a release. There are a few outstanding requests that I was *not* able to consider for 0.6 because the required changes would've been too disruptive to stability. They have been bumped to the 0.7 list to receive further consideration after 0.6 final is released: * A request to change the PYTHONPATH resolution order * A request to allow installed scripts to use -O * Adding XML-RPC support for PyPI

5 19