Mailman 3 November 2006 - Distutils-SIG

Package versioning
by Timothy Docker April 29, 2018

April 29, 2018

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 April 29, 2018

April 29, 2018

3 2

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

May 29, 2009

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

Building an egg from Subversion using zc.buildout
by Nathan R. Yergler Feb. 12, 2007

Feb. 12, 2007

I'm using zc.buildout for deploying a handful of applications, and one of our dependencies doesn't have eggs or "correctly" formatted pages (that would allow easy_install to track down the repository for direct building from source). Does zc.buildout provide any way to build an egg from a Subversion URL? Something with similar behavior to: easy_install -m -d ./eggs http://path/to/svn/repos I'm happy to write a recipe if necessary, just thought I'd make sure someone else hadn't already scratched this itch. Thanks, Nathan

5 40

bdist_rpm fails due to bytecompiled modules
by Christopher Blunck Dec. 6, 2006

Dec. 6, 2006

hello, i have a very basic pure-python package and script that i would like to distribute as a noarch rpm using distutils. i am using FC5 as my development platform and have prepared a setup.py that properly builds and installs my application. the first problem i have is that the bdist_rpm command results in an %install section as follows: %install python setup.py install --single-version-externally-managed --root=$RPM_BUILD_ROOT --record=INSTALLED_FILES the trouble here with that %install section is that the python modules get bytecompiled and thus turned into native code. i'd prefer for that not to happen, so i have written my own install.sh script and i provide that to my python setup.py call as follows: $ python setup.py bdist_rpm --spec-only --install-script /path/to/install.sh my install.sh passes the --optimize 0 and --no-compile arguments to distutils, resulting in no .pyc or .pyo files being installed in my RPM_BUILD_ROOT. the contents of my install.sh are as follows: python setup.py install --single-version-externally-managed --root=$RPM_BUILD_ROOT --record=INSTALLED_FILES --optimize 0 --no-compile i thought that would result in no byte compiled files but unfortunately i was wrong. i'm not sure what's causing it, but rpmbuild ends up calling brp-python-bytecompile to compile the .py files. i noticed in the ChangeLog for rpm the following: - force *.py->*.pyo byte code compilation with brp-python-bytecompile. so it appears to me as tho there is no way to assemble a noarch RPM using distutils. does that sound accurate to you all? or are those folks out there using distutils and an old version of rpm (prior to 2005) that are able to assemble noarch RPMs? -c -- WeatherNet Observations for station: home Temperature: 54.80F Pressure: 30.02in; Dew Point: 30.76F (40%) Wind: 248 at 5 mph Recorded: 17:54:59 10/25/06 (http://wsdl.wxnet.org/inquiry/binding.wsdl)

5 8

buildout and zc.recipe.egg:custom problems
by Martijn Faassen Dec. 3, 2006

Dec. 3, 2006

Hi there, I'm trying to induce zc.buildout's zc.recipe.egg:custom recipe to build a library (lxml) against C libraries (libxml2, libxslt) installed in a custom place, i.e. as parts, such as parts/libxml2/include and parts/libxml2/lib. I thought I had that working before and even blogged about it, but it turns out that something's not entirely right yet. Right now I'm struggling to actually see an 'include-dirs' directive to have any effect on what's passed along to the C-compiler (namely the -I) option. It doesn't. After some research I think I've figured out why. I've installed lxml as a development egg, and somehow it always gets built the default way. The custom egg's install code is reached, but only when it's too late and lxml is already built. Therefore any special options such as include-dirs and library-dirs are never passed, as lxml has already been created. I figure lxml gets created automatically and not through the custom recipe as I have it listed as a develop egg in the [buildout] section. What to do about this? Regards, Martijn

2 2

Re: [Distutils] SetupTools: The Case Of The Installed Egg
by Phillip J. Eby Nov. 30, 2006

Nov. 30, 2006

At 03:46 PM 11/20/2006 -0500, Alexander Michael wrote: >On 11/19/06, Phillip J. Eby <pje(a)telecommunity.com> wrote: > > At 12:41 PM 11/18/2006 -0500, Alexander Michael wrote: > > >It looks like SetupTools now attempts to lower case everything, but > > >doesn't in the case of an explicit install. Bug or feature? > > > > Neither; it's a meaningless quirk caused by the fact that easy_install > > doesn't case-normalize egg paths supplied via the command line. (Virtually > > everything else it does is with paths that are "absolutized" and > > case-normalized.) It doesn't cause any problems, if that's what you're > > wondering. > >Yep. Just wondering if it will bite me later (in linux or cygwin). The >thing that concerned me most was that the case of entry inside the >easy-install.pth file (all lower) disagreed with what was on the file >system (mixed case as specified in setup.py). The different cases >resulting from installation method is also a hobgoblin of my little >mind, but if it causes no ill, then I can deal with the haunting. > >Since there is uncertainty in case, is there an easy way with >pkg_resources to ask if a particular package is _installed in >easy-install.pth_ and meets a given version requirement. For example, >something like pkg_resources.isinstalled("MyPackage>=3.2")? pkg_resources.working_set.find('MyPackage>=3.2') will return a true value (a distribution object) if a matching package is currently on sys.path. If 'MyPackage' is on sys.path but doesn't match the version requirement, a VersionConflict error is raised. If it's not on sys.path, None is returned.

2 1

Re: [Distutils] Specifying a compiler
by Phillip J. Eby Nov. 30, 2006

Nov. 30, 2006

At 05:28 PM 11/29/2006 -0700, Robert McFadzean wrote: >The documentation indicates that one can specify a compiler as in build >--compiler=vc98. Actually, you have to use one of these: $ python setup.py build --help-compiler List of available compilers: --compiler=bcpp Borland C++ Compiler --compiler=cygwin Cygwin port of GNU C Compiler for Win32 --compiler=emx EMX port of GNU C Compiler for OS/2 --compiler=mingw32 Mingw32 port of GNU C Compiler for Win32 --compiler=msvc Microsoft Visual C++ --compiler=mwerks MetroWerks CodeWarrior --compiler=unix standard UNIX-style compiler >I have Visual Studio VC98 C++ 6.0 vc98 doesn't work to specify the >compiler. Does anyone know how I would specify it so setup will use what >I have, rather than looking for VC7.0 that was used to compile python? I suspect the answer is that you can't, and have it still work. You probably have to download one of the "free" MS compilers. There may also be some sort of environment variable and/or registry hacking that can be done to force Python to use your older compiler, but it's not clear that the resulting extensions will actually work with your Python. Alternately, you can use the free MinGW compiler. See: http://www.mingw.org/MinGWiki/index.php/Python%20extensions for one possible source of instructions.

1 0

Specifying a compiler
by Robert McFadzean Nov. 30, 2006

Nov. 30, 2006

The documentation indicates that one can specify a compiler as in build --compiler=vc98. I have Visual Studio VC98 C++ 6.0 vc98 doesn't work to specify the compiler. Does anyone know how I would specify it so setup will use what I have, rather than looking for VC7.0 that was used to compile python? Robert G. McFadzean Instructor Vermilion School of Agriculture Lakeland College 5707 47 Ave West Vermilion AB T9X 1K5 Tlf: (780) 853-4890 Fax: (780) 853-8704 robert.mcfadzean(a)lakelandc.ab.ca

2 1

parse_version() with '-'
by Pascoe, S (Stephen) Nov. 29, 2006

Nov. 29, 2006

I've just noticed pkg_resources.parse_version() doesn't appear to follow the setuptools documentation with regards 'rc' vs. '-rc'. With setuptools-0.6c3: Python 2.4.1 (#1, Oct 13 2006, 16:58:04) [GCC 4.0.2 20050901 (prerelease) (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from pkg_resources import parse_version >>> parse_version('2.1-rc2') < parse_version('2.1') True >>> parse_version('2.1rc2') < parse_version('2.1') True >>> This contradicts the docs and suggests a '-' no longer differentiates pre and post releases. Is this a bug or feature? Thanks, Stephen. --- Stephen Pascoe 01235 445980 British Atmospheric Data Centre Rutherford Appleton Laboratory, CCLRC

1 0