Mailman 3 May 2008 - Distutils-SIG

Fwd: setuptools: Spelling < 3.1.0beta3 ?
by Alexander Michael May 2, 2008

May 2, 2008

On Fri, May 2, 2008 at 12:30 PM, Pete <pfein(a)pobox.com> wrote: > Hi- > > What's the proper way to spell "any version in the 3.0.x series" if a > project has a 3.1.0beta3 release? > > Specifically, CherryPy has both 3.0.2 and 3.1.0beta3 releases. I'd like to > depend on any 3.0.x > > I've tried both 'CherryPy < 3.1' and 'CherryPy < 3.1.0' in my > install_requires, and both cause setuptools to pull 3.1.0beta3. > > I realize I can use 'CherryPy == 3.0.2' but that defeats the "any 3.0.x" > idea... I find this surprising as well, but the answer is: >>> import pkg_resources >>> v = pkg_resources.parse_version >>> v('3.1.0beta3') < v('3.1.0') True >>> v('3.1.0beta3') < v('3.1.0a0') False I wish it was "easier" to say "3.1.x" (as in any final sub-point release in the 3 series) or "1.x" (as in any final version 1 release) which didn't allow development, alpha, beta, candidate, etc. releases. Is there?

2 1

setuptools: Spelling < 3.1.0beta3 ?
by Pete May 2, 2008

May 2, 2008

Hi- What's the proper way to spell "any version in the 3.0.x series" if a project has a 3.1.0beta3 release? Specifically, CherryPy has both 3.0.2 and 3.1.0beta3 releases. I'd like to depend on any 3.0.x I've tried both 'CherryPy < 3.1' and 'CherryPy < 3.1.0' in my install_requires, and both cause setuptools to pull 3.1.0beta3. I realize I can use 'CherryPy == 3.0.2' but that defeats the "any 3.0.x" idea... --Pete

1 0

setuptools on 64 bit Windows broken?
by Jeroen Ruigrok van der Werven May 2, 2008

May 2, 2008

[Apologies if this was discussed in the past, I did some searching but couldn't find much, but then again my attention is spread a little too thing lately.] Right now setuptools on Windows x64 with 64-bits Python 2.5 is (partially) broken. The error shown is: Cannot find Python executable C:\Python25\python.exe when running easy_install. The phrase comes from launcher.c which is compiled via MingW to cli.exe and gui.exe. Both of these are present in the setuptools repository and are 32-bits only for all I can determine (using file). I have not thoroughly checked it yet (due to being written in Unix-C, even though it's aimed at Windows), but my guess is it's using some API calls which fail on 64-bits Windows. I see there's a mingw-64 toolkit on the 'net nowadays. Has anyone tried this yet? Is it indeed an API issue? Furthermore, when creating an egg on Windows x64, it will create it with an identifier of win32, even though C code in a project is compiled with an AMD64 version of the compiler. For all I know 32-bits Windows systems will also pull down this version of the egg when given the chance. I guess this is due to Python 2.5 64 bit reporting win32 for sys.platform? So don't we miss something to properly distinguish between 64 bits Windows and 32 bits? Especially with x64 and Vista 64 on the market nowadays? Thanks for any pointers/clues... -- Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai イェルーンラウフロックヴァンデルウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Whoever undertakes to set himself up as judge in the field of truth and knowledge is shipwrecked by the laughter of the Gods.

2 1

Re: [Distutils] [Python-Dev] shal we redefine "module" and "package"?
by glyph＠divmod.com May 1, 2008

May 1, 2008

On 10:53 pm, steve(a)holdenweb.com wrote: >zooko wrote: >>Unfortunately these answers aren't quite right. A "package" is >>actually a directory containing an __init__.py file, and a >>distribution is actually what you think of when you say "package" -- a >>reusable package of Python code that you can, for example, get from >>the Python package index. The fact that the Python "package" index is a place where you get "distributions" does seem a bit weird to me, but this is not necessarily a problem that can be fixed. Ambiguity is part of human language. Perhaps suggest transliterations of these terms for talking about python in lojban? :) >>1. A "module" shall henceforth be the name for either a foo.py file >>(a single-file module), or a directory with an __init__.py in it (a >>directory module). I have a less disruptive counterproposal. How about just starting to refer to directories (or "folders", or zip entries) with '__init__.py' in them as "package modules"? A package is-a module anyway. >>2. A "package" shall henceforth be the name of the thing that is >>currently called a "distribution". I belive a multi-word term here would be similarly more memorable and precise. A "package distribution" would include the more familiar term while still being specific, consistent with the old terminology, and correct. Using a qualifying word is probably a good idea in this context anyway. I usually say "debian package", "RPM", "MSI", or "tarball" unless I'm specifically talking about "packages for your platform", almost always in the phrase, "please do not use distutils to do a system install of Twisted, use the specific package for your platform". >-1 I do, however, agree with Steve emphatically on your original proposal. Changing the terminology now will make billions upon billions of Python web pages, modules (c.f. twisted.python.modules.PythonModule.isPackage()) documents, and searchable message archives obsolete, not to mention that 90% of the community will probably ignore you and use the old terminology anyway, creating more confusion than it eliminates.

3 4

Setuptools Bug: all files installed +x
by Pete May 1, 2008

May 1, 2008

On both linux & OS X, Setuptools installs all .py/.pyc files with mode a+x (executable for all users). This occurs regardless of original the permissions in the source tarball. Doing so breaks nosetests, which by default refuses to import executable files for test-discovery purposes as a safety measure. This behavior is broken & dangerous. -- Pete pfein(a)pobox.com

6 11

easy_install path
by Michael Hearne May 1, 2008

May 1, 2008

I'm having a problem with easy_install and a library I just installed. I have a Mac OS 10.5 (Leopard), and I used the SciPy SuperPack installer (http://macinscience.org/?page_id=6) to install a whole bunch of scientific packages, including matplotlib. I then used easy_install to install Basemap, which is a "toolkit" based on matplotlib. The usual instructions for Basemap have the import statement like this: from matplotlib.toolkits.basemap import Basemap However, when I try this in Python, I get an ImportError. This obviously has something to do with the path that Python uses to find libraries, and I found an easy_install.pth file that looks like this: ------------------------------------------------------------------ ./setuptools-0.6c8-py2.5.egg ./readline-2.5.1-py2.5-macosx-10.5-i386.egg ./ipython-0.8.3.svn.r3001-py2.5.egg ./numpy-1.1.0.dev5077-py2.5-macosx-10.3-i386.egg ./matplotlib-0.98pre-py2.5-macosx-10.3-i386.egg ./scipy-0.7.0.dev4174-py2.5-macosx-10.3-i386.egg ./pymc-2.0DEV_r709-py2.5-macosx-10.3-i386.egg ./nose-0.10.1-py2.5.egg ./basemap-0.9.9.1-py2.5-macosx-10.5-i386.egg import sys; new=sys.path[sys.__plen:]; del sys.path[sys.__plen:]; p=getattr(sys,'__egginsert',0); sys.path[p:p]=new; sys.__egg insert = p+len(new) ------------------------------------------------------------------ Any clues as to what is going on, and how I can fix the problem? Thanks, Mike ------------------------------------------------------ Michael Hearne mhearne(a)usgs.gov (303) 273-8620 USGS National Earthquake Information Center 1711 Illinois St. Golden CO 80401 Senior Software Engineer Synergetics, Inc. ------------------------------------------------------

1 0

shal we redefine "module" and "package"?
by zooko May 1, 2008

May 1, 2008

Folks: Here's an experiment you can perform. Round up a Python programmer and ask him the following three questions: Q1. You type "import foo" and it works. What kind of thing is foo? Q2. You go to the Python package index and download something named "bar-1.0.0.tar.gz". What kind of thing is bar? Q3. What is a "distribution"? I'm willing to bet that you will get the following answers: A1. foo is a module. A2. bar is a package. A3. A distribution is a version of Linux that comes with a lot of Free Software. Unfortunately these answers aren't quite right. A "package" is actually a directory containing an __init__.py file, and a distribution is actually what you think of when you say "package" -- a reusable package of Python code that you can, for example, get from the Python package index. Educational efforts such as the Python tutorial and the distutils docs have not succeeded in training Python programmers to understand the terminology for these things as used by the Python implementors, so perhaps instead the implementors should start using the terminology understood by the programmers: 1. A "module" shall henceforth be the name for either a foo.py file (a single-file module), or a directory with an __init__.py in it (a directory module). 2. A "package" shall henceforth be the name of the thing that is currently called a "distribution". Regards, Zooko who doesn't mind stirring up trouble on occasion...

4 3