
At 09:45 AM 6/19/2007 -0500, Edward Ream wrote:
1. On both XP and Ubuntu, running
python setup.py bdist_egg
gives a .egg file with a suffix of py2.5.egg, even though the version arg to setup is '4.4.3preview9' I was expecting a suffix of all.egg, because platforms = ['all',] Can anyone explain what is going on?
Eggs are named in the form "projectname-version-pythonversion[-optionalplatform].egg"; if you do not include any platform-specific code, the platform suffix is omitted. The Python version is included because .pyc and .pyo files are specific to a particular version of Python. (Also, the 'platforms' argument to setup() has no effect on the platform suffix or whether there is one. It's a recently introduced feature in newer Pythons that only affects the generation of PKG-INFO files.)
2. The resulting egg file is much larger than the .zip file created by 'python setup.py sdist' in spite of exclude_package_data = { '': ['*.pyc','*.pyo']},
Is there any way to exclude .pyc and .pyo files?
No; you can exclude the source if you like, though, with --exclude-source-files. Eggs are a binary distribution format, originally developed to support user-installed plugins for systems like Chandler, Zope, etc. They aren't a source distribution format; sdist works well enough for that and for easy_install if you have a pure-Python package (or your users have C compilers).
3. 'python setup.py register' works fine, but 'python setup.py upload' fails with an 'invalid request' returned from the server. Maybe because the egg is over 8Meg?
I have no idea; I'd suggest using the --show-response option so you can see what's happening.
4. 'easy_install leo' is supposed to use the download_url link arg. This is a great idea. Alas, for me it is spoiled by the setuptools pre/post release naming convention. The problem is that this convention is applied to all the links on the download_url page. Because I can't upload to the Python Cheese Shop, I used Leo's SourceForge download page for the main Leo project. The setup.py script is supposed to find the latest release on the page, but setup.py thinks that the latest match is something like Leo-4.2.1.zip (!!) This in spite of the fact that Leo-4.4.3rc1.zip exists on the page.
I don't follow you; here's the output from my attempt at downloading from the SF page: $ easy_install -nvf http://sourceforge.net/project/showfiles.php?group_id=3458 leo Searching for leo Reading http://sourceforge.net/project/showfiles.php?group_id=3458 Best match: leo 4.4.3preview8 Downloading http://downloads.sourceforge.net/leo/leo-4.4.3preview8.zip?modtime=118208851... Perhaps you've changed something else?
5. setuptools is advertised as an 0.x release. This post appeared over a year ago,
http://bitworking.org/news/Please_stop_using_setuptools__at_least_exclusivel...
This post may be obsolete, but it troubles me. I suppose I wouldn't worry so much were it not for these other issues.
The issues reported in that post were fixed within days of the blog posting; they'd have been fixed even faster if its author had actually asked about the issues here. Setuptools is currently at 0.6c6. There are a handful of known issues and quirks remaining, but it is otherwise pretty darn stable.