Mailman 3 February 2007 - Distutils-SIG

Cheesecake service
by Michał Kwiatkowski 14 Feb '07

14 Feb '07

Hi, On top of PyPI and Cheesecake I've build a Cheesecake service - a service which automatically downloads and scores new package releases. It is available at this address: http://pypi.pycheesecake.org/pypi/ . Probably of most interest here is the easy_installability page (http://pypi.pycheesecake.org/pypi/easy_installability) which shows releases which are listed on PyPI, yet still can't be easy_installed. If this feature proves itself to be reliable it could probably substitute a list of successful installations on http://peak.telecommunity.com/DevCenter/PackageNotes . I'm open to any suggestions on how this service can be improved. You can learn more about Cheesecake principles in this recent blog post: http://mousebender.wordpress.com/2007/02/09/cheesecake-for-all/ . Cheers, mk

2 2

pkg_resources._macosx_vers without using os.popen
by Ronald Oussoren 13 Feb '07

13 Feb '07

Philip, The attached patched replaces pkg_resources._macosx_vers by a function that directly parses the relevant XML file instead of using sw_vers. The patch is an svn diff relative to the trunk. The main reason I prefer this version is that I'm debugging some C code in a project using setuptools using command-line gdb (who needs IDE's?) and I often (but not always) get I/O errors when reading from a pipe to a forked-off process when running python from gdb. With this patch pkg_resources no longer forks of processes and gdb is happy. When you're not using gdb there's little reason to prefer this version over the original one. Ronald

1 0

setuptools 0.6c5 released :(
by Phillip J. Eby 13 Feb '07

13 Feb '07

I found some upload and bdist related issues while uploading 0.6c4, so I've fixed them and released 0.6c5. If you haven't seen the release announcement for 0.6c4 yet, it's because it has been held for moderation because of "a suspicious header". Why the release of setuptools 0.6c4 is considered suspicious, I don't know. Hopefully this message won't also be considered suspicious. :(

3 4

Whose problem is this?
by skip＠pobox.com 13 Feb '07

13 Feb '07

I noticed that some easy_installed packages don't seem to support online help in my environment at work (Solaris 10/x86, Python 2.4.2). Here's an example: % python Python 2.4.2 (#1, Feb 23 2006, 12:48:31) [GCC 3.4.1] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import sqlalchemy >>> sqlalchemy.__file__ '/opt/app/g++lib6/python-2.4/lib/python2.4/site-packages/SQLAlchemy-0.3.3-py2.4.egg/sqlalchemy/__init__.pyc' >>> help(sqlalchemy) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/opt/app/g++lib6/python-2.4/lib/python2.4/site.py", line 328, in __call__ return pydoc.help(*args, **kwds) File "/opt/app/g++lib6/python-2.4/lib/python2.4/pydoc.py", line 1647, in __call__ self.help(request) File "/opt/app/g++lib6/python-2.4/lib/python2.4/pydoc.py", line 1691, in help else: doc(request, 'Help on %s:') File "/opt/app/g++lib6/python-2.4/lib/python2.4/pydoc.py", line 1475, in doc pager(title % desc + '\n\n' + text.document(object, name)) File "/opt/app/g++lib6/python-2.4/lib/python2.4/pydoc.py", line 295, in document if inspect.ismodule(object): return self.docmodule(*args) File "/opt/app/g++lib6/python-2.4/lib/python2.4/pydoc.py", line 1052, in docmodule for file in os.listdir(object.__path__[0]): OSError: [Errno 20] Not a directory: '/opt/app/g++lib6/python-2.4/lib/python2.4/site-packages/SQLAlchemy-0.3.3-py2.4.egg/sqlalchemy' Online help for setuptools itself works fine though. Is that a pydoc problem, a Python problem, an easy_install problem or what? I get the same result when I try to get help about Elixir. Skip

2 1

Compiler support for VC++ 2005
by Howard Lightstone 12 Feb '07

12 Feb '07

I am unable to rebuild things using disutils using Visual Studio 2005. I get reports of "No compiler found". Since VC8 is the only thing available in the future (from Micro$soft), is there any progress toward updating distuils to allow this compiler (and its own locations....) to be supported?

4 11

Re: [Distutils] Setuptools: omit namespace package directories?
by Phillip J. Eby 12 Feb '07

12 Feb '07

At 08:59 AM 2/12/2007 +0100, Thomas Lotze wrote: >Phillip J. Eby wrote: > > > It appears your goals are somewhat... confused. > >I don't think so. I'm sure I still have to learn about setuptools but I >think I know quite well what I want to achieve. I meant the operational goals for the code you wrote, not your overall goal. > > Remember that by definition a namespace package has no single "owner" > > project. It is potentially shared across multiple projects. When > > installed as an egg, each __init__.py is executed, true. But when a > > project is NOT installed via egg, but rather by a system packager, the > > __init__.py doesn't exist, and so cannot be executed. > >If we have to take into account distributions of a project as source code >bereft of its top-level namespace's __init__.py being expected to just >work, I give up. I assumed to always work with either intact source or >built eggs, the latter with or without their namespaces' __init__.py files >being used and with or without being installed by our egg tools. Built eggs contain namespace package __init__.py files, system-installed eggs do not. >The package remapping is only needed when running from source, and I don't >see a reason why the __init__.py shouldn't exist and be executed in that >case. Because 1) it won't be the only __init__.py for the package, and 2) how does it help you avoid having subdirectories for namespace packages? You still have to have the directory to put the __init__.py in, and deeply nested namespace packages aren't a very good idea to begin with. If it's only one or two layers deep, it's just as easy to do it the standard way, without package_dirs. > > Therefore, your prototype code is horribly broken, as it will corrupt > > pkg_resources' internal data structures when it is run more than once -- > >I don't see why it couldn't be made to behave properly. Perhaps it could. I just don't see how! In order to set up the __path__'s for a specific project, the __init__.py must have knowledge of *that* project. Therefore, *each* project must contain such a file, *and* it must be executed. Under setuptools 0.6, it's currently the case that all namespace package __init__'s (except those installed as system packages) are executed. However, under setuptools 0.7, *at most one* will be -- which means that only *one* project will have a chance to do this munging, for its own paths. (All of these things I'm saying are documented in the setuptools manual under the "Namespace Packages" heading, by the way.) > > (And I won't even get into the > > pointlessness of wrapping module-level code in an import lock.) > >I'd appreciate it if you did, as I haven't yet found a difference between >using the lock in modules and using it in pkg_resources.declare_namespace >which is being called by modules. Runtime code that requests activation of an egg can currently result in declare_namespace() being called (see Distribution.activate()), and the import lock thus won't be held at that point in time.

2 1

Better error reporting
by Jim Fulton 12 Feb '07

12 Feb '07

There are places where setuptools exceptions sometimes lack important information. For example, in PackageIndex.open_url, there is: def open_url(self, url): if url.startswith('file:'): return local_open(url) try: return open_with_auth(url) except urllib2.HTTPError, v: return v except urllib2.URLError, v: raise DistutilsError("Download error: %s" % v.reason) Getting a download error without knowing what the error is for is rather frustrating. :) IMO, this should be: def open_url(self, url): if url.startswith('file:'): return local_open(url) try: return open_with_auth(url) except urllib2.HTTPError, v: return v except urllib2.URLError, v: raise DistutilsError("Download error for %r: %s" % (url, v.reason)) Phillip, would you like me to go ahead and make minor changes like this? Or would you rather make them yourself? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

2 1

Re: [Distutils] Setuptools: omit namespace package directories?
by Phillip J. Eby 11 Feb '07

11 Feb '07

At 05:05 PM 2/8/2007 +0100, Thomas Lotze wrote: >Hi, > >when using namespace packages, the corresponding package directories and >__init__.py files must physically exist in the source tree, even though >they can't, by definition of a namespace package, contain anything other >than subordinate directories and a fixed stanza of Python code, resp. I'm not sure that's entirely true, although they *do* have to exist when using "setup.py develop", or they won't be importable. Have you tried using the distutils package_dir mapping to remap your source tree? >This gets annoying, especially when using nested namespaces. For example, >when writing a buildout recipe, the cleanest thing is to use several >namespaces, like zc.recipe.egg does. As Jim points out, nested namespace packages are usually a bad idea and shouldn't be created for new systems, as entry points are a better way of supporting third-party extensions to a package. Thus, having a single top-level namespace to denote a publisher or product line is usually sufficient. >However, you end up jumping through >essentially empty directories all the time while working on the source. >There's evidence that this problem is a real one: buildout recipes >registered with PyPI tend to omit the "recipe" part at the expense of >namespace hygiene and PEP 8 compliance, for example gocept.download or >buildout_script. I don't understand. >Since there's basically not information in those boilerplate directories >and __init__.py files that couldn't be inferred from a keyword parameter >to setup(), would it be a sensible feature request that setuptools do >without the physical namespace directories in the future? As I said, I'm not sure it needs them *now*, except to support setup.py develop. I'm not really fond of the package_dirs feature, preferring to use an importable layout when I do development. But the feature does exist and please feel free to let me know whether it solves your problem, or report *specifically* what it does or does not do correctly and what output is produced. Thanks.

3 11

Building an egg from Subversion using zc.buildout
by Nathan R. Yergler 11 Feb '07

11 Feb '07

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

ez_setup.py -U setuptools does TWO downloads, TWO installs
by John Machin 10 Feb '07

10 Feb '07

Is this usual? The ez_setup.py is fresh off the setuptools website. Environment: Python 2.5; Windows XP Pro SP2 Console log follows. Cheers, John ====================================================================== C:\sw\setuptools>\python25\python ez_setup.py -U setuptools Downloading http://cheeseshop.python.org/packages/2.5/s/setuptools/setuptools-0.6c5-py2… Searching for setuptools Reading http://www.python.org/pypi/setuptools/ Reading http://cheeseshop.python.org/pypi/setuptools Reading http://www.python.org/pypi/setuptools/0.6c5 Best match: setuptools 0.6c5 Downloading http://cheeseshop.python.org/packages/2.5/s/setuptools/setuptools-0.6c5-py2… Processing setuptools-0.6c5-py2.5.egg Moving setuptools-0.6c5-py2.5.egg to c:\python25\lib\site-packages Removing setuptools 0.6c3 from easy-install.pth file Adding setuptools 0.6c5 to easy-install.pth file Installing easy_install-script.py script to C:\python25\Scripts Installing easy_install.exe script to C:\python25\Scripts Installing easy_install-2.5-script.py script to C:\python25\Scripts Installing easy_install-2.5.exe script to C:\python25\Scripts Installed c:\python25\lib\site-packages\setuptools-0.6c5-py2.5.egg Processing dependencies for setuptools Processing setuptools-0.6c5-py2.5.egg Removing c:\python25\lib\site-packages\setuptools-0.6c5-py2.5.egg Copying setuptools-0.6c5-py2.5.egg to c:\python25\lib\site-packages setuptools 0.6c5 is already the active version in easy-install.pth Installing easy_install-script.py script to C:\python25\Scripts Installing easy_install.exe script to C:\python25\Scripts Installing easy_install-2.5-script.py script to C:\python25\Scripts Installing easy_install-2.5.exe script to C:\python25\Scripts Installed c:\python25\lib\site-packages\setuptools-0.6c5-py2.5.egg Processing dependencies for setuptools==0.6c5 C:\sw\setuptools>

2 4