Mailman 3 December 2009 - Distutils-SIG

[issue98] easy_install installs an old version of matplotlib
by Daniel Brown Dec. 9, 2009

Dec. 9, 2009

New submission from Daniel Brown <endlessly.curious(a)gmail.com>: 'easy_install matplotlib' results in matplotlib version 0.91.* being installed. The latest version on matplotlib is 0.99.*. I have tried this on Mac and PC (via Cgywin). ---------- messages: 472 nosy: Danielb priority: bug status: unread title: easy_install installs an old version of matplotlib _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue98> _______________________________________________

1 0

Proposing PEP 386 - a standard version scheme
by Tarek Ziadé Dec. 8, 2009

Dec. 8, 2009

(This is the email I will send to python-dev, so everyone can review it before it is sent) On behalf of the Distutils-SIG, I would like to propose PEP 386 for inclusion in the sdtlib, and have a final discussion here on Python-dev. http://www.python.org/dev/peps/pep-0386 This PEP has been discussed for some time in Distutils-SIG, and we agreed there that it's important to have it accepted for the future of packaging because: 1/ it will offer interoperability for all Python package managers out there. (namely: Distutils, Distribute, Setuptools, Pip, PyPM) 2/ it will provide a reference for OS packagers, so they can translate automatically Python distributions versions in their own schemes. Choosing a schema was quite controversial because every development team have their own version scheme. But notice that it is not in the scope of this PEP to come up with an universal versioning schema, intended to support many or all existing versioning schemas. There will always be competing grammars, either mandated by distro or project policies or by historical reasons and we cannot expect that to change. The goal of this PEP is rather to provide a standard reference schema that is able to express the usual versioning semantics, so it's possible to parse any alternative versioning schema and transform it into a compliant one. This is how OS packagers usually deal with the existing version schemas and is a preferable alternative than supporting an arbitrary set of versioning schemas. As I expected, we didn't find a full consensus on the final PEP 386 schema on Distutils-SIG. But the one presented is good enough for what we need to express, as far as I am concerned (and some other people). This status understandable, and can go on for months in distutils-SIG. So I am proposing to see this PEP discussed for one more round here, then rejected or approved by the highest authority :) so we can move on to the final changes we are planning on PEP 345 and PEP 376 (those are the next PEP we want to propose here) Regards Tarek

4 7

RFC822, PKG-INFO and the Description field
by Tarek Ziadé Dec. 7, 2009

Dec. 7, 2009

Hi, I am currently fixing a bug in Distutils: http://bugs.python.org/issue1923 this bugs makes a Description field like: """ Text:: a literal python block:: >>> import this """ Transformed into : """ Text:: a literal python block:: >>> import this """ Which is fine for RFC822 compliancy but sucks for reST if someone wants to parse it back. There's another problem: empty lines. For instance: """ Description: Text:: a literal python block:: >>> import this """ Will not be parseable with rfc822 because the first empty line ends the header. IOW we need to encode that multi-line field differently. I want to take the chance that we are changing PEP 345, to introduce a smarter marker in 1.2, that will add a character (:) after the 8 spaces to avoid losing empty lines: """ Description: Text:: : :a literal python block:: : : >>> import this """ So we are able to unparse it. Thoughts ? Regards Tarek

3 3

PEP 386 status - last round here ?
by Tarek Ziadé Dec. 7, 2009

Dec. 7, 2009

Hello, PEP 386 seem to be ready, and I would like to push if for feedback at python-dev, just before PEP 345 is pushed. My only concern is now to make sure the PEP motivations and explanations are crystal clear. Anyone see any problem ? or have any concern with this PEP ? This PEP is the basis for PEP 345 acceptation. Regards Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与

11 75

installing .py plugins to an alternate directory
by Andrew Dalke Dec. 5, 2009

Dec. 5, 2009

Hi all, I'm working with the Akara project. It contains a web server. The server loads extensions from a special directory (let's say "$AKARA" for now). An extension can register handlers for URLs. An example extension might look like: installs to $AKARA/spam_extension.py (note: only .py files are supported; not even .pyc files) ========================= from akara.services import simple_service import my_spam # This is part of the distribution, and gets put in site-packages @simple_service("GET", "http://vikings.protocol.id/") def vikings(say=my_spam.DEFAULT_TEXT): return my_spam.vikings(say) ========================= We want people to be able to distribute Akara plugins and install via setup.py. Ideally I would like to say: from distutils.core import setup from akara.distutils ... I'm not sure what here ... setup(name="Spam services", package="my_spam", akara_extensions=["spam_extension.py"] ) To clarify, the development/distribution package looks like: $PACKAGE/setup.py $PACKAGE/README $PACKAGE/spam_extensions.py $PACKAGE/my_spam/__init__.py $PACKAGE/my_spam/dramatis_personae.py $PACKAGE/my_spam/cafe.py and $PACKAGE/spam_extensions.py goes to $AKARA/spam_extensions.py while $PACKAGE/my_spam is copied to site-packages. The installation does not need to byte-compile spam_extension.py. It should also include spam_extension.py in any distribution that it makes. I looked through the documentation and searched for existing examples, but found nothing which does this. The plugins I found used entry_points, and that's an architecture change which I don't think is appropriate for us. Suggestions? I had hoped that I could add my own cmdclasses like "build_akara" and "install_akara" which would get called during the correct stages of the build process, but that seems to be a dead end. I might be able to hack the "install_data" cmdclass to make it work, but that would prevent anyone from using it in their own setup.py distributions. Andrew dalke(a)dalkescientific.com

7 17

setuptools-0.6c11 package_index.py 475 return dist.clone ?
by denis Dec. 4, 2009

Dec. 4, 2009

Folks, in setuptools-0.6c11-py2.6.egg/setuptools/package_index.py lines 468-475 if dist is None: ... return dist.clone(...) => of course AttributeError: 'NoneType' object has no attribute 'clone' return None if dist is None else dist.clone(...) fixes yolk. (Does nobody else use yolk ? I like it, less is more; which of this year's new package managers have the same functionality ?) Sorry if this is a duplicate or the wrong place to post. cheers -- denis

3 2

install_requires option to force pypi url?
by Aljoša Mohorović Dec. 4, 2009

Dec. 4, 2009

i've setup private pypi where i can upload some packages that are not suitable for pypi.python.org. my package, let's call it myapp, contains "install_requires=['django',]" but with that requirement i can't install it. -------------------------------------------------- $ virtualenv --no-site-packages --distribute env New python executable in env/bin/python A globally installed setuptools was found (in /usr/lib/python2.6/dist-packages) Use the --no-site-packages option to use distribute in the virtualenv. Installing distribute...........................................................................................................................................................................done. $ . env/bin/activate $ pip freeze distribute==0.6.8 wsgiref==0.1.2 $ pip install myapp -i http://pypi.example.com Downloading/unpacking myapp Using download cache from /home/aljosa/.pip-cache/<MYAPP PKG URL> Running setup.py egg_info for package myapp Downloading/unpacking django (from myapp) Could not find any downloads that satisfy the requirement django (from myapp) No distributions at all found for django (from myapp) -------------------------------------------------- since i can normally install django with "pip install django" i assume that when i set "-i http://pypi.example.com" it's also used for install_requires. any tips on using multiple pypi repositories? is there some way to define which pypi url to use for package installation? Aljosa Mohorovic

1 0

PEP 345 - 3 new fields
by Tarek Ziadé Dec. 4, 2009

Dec. 4, 2009

Hello As suggested in Catalog-SIG by some people, I would like to propose the addition of three more fields for 1.2: "Repository-URL" A string containing the URL for the package's repository. Example: http://svn.python.org/projects/python/trunk/ "Repository-Browse-URL" A string containing the URL for the package's browsable repository. Example: http://svn.python.org/view/python/trunk "Bug-Tracker-URL" A string containing the URL for the package's bug tracker Example: http://bugs.python.org/ Any thoughts ? Tarek

10 41

Enumerating packages in a distribution
by Celvin Dec. 4, 2009

Dec. 4, 2009

Hi, I recently implemented a plugin system using setuptools, and now I'm wondering how to enumerate the packages contained in a given Distribution object. What I'm doing is basically this: I use egg files as self-describing plugins to allow users to distribute plugins containing several packages, with each package providing a set of functions that are registered and loaded into a GUI's menu at runtime. The way each function in a given package is displayed in the GUI is encoded into a XML file that is distributed with each package, i.e. users can add several packages to the distribution, declare the entry points and create an XML file that will describe each package's menu structure like this: foo/ foo/ __init__.py setup.py package1/ menu.xml functions1.py package2/ menu.xml functions2.py ... Accessing the XML files via pkg_resource.resource_stream(__name__, "menu.xml") works just fine from inside functionX.py, but since the combination of working_set.find_plugins and working_set.iter_entry_points returns a loose list of EntryPoint instances without preserving the package structure, I have trouble mapping an EntryPoint to the matching menu.xml file, while only parsing the XML file just once and not for each entry point. In the past, I used the module_name attribute of the EntryPoint instances to build a path to be used with the IResourceProvider API implemented in each Distribution instance like this: dist.get_resource_stream(__name__, "%s/menu.xml" % (entry_point.module_name, )) ...but since the user creating a plugin is free to nest the package further, the module_name might not be identical to the package name where the menu.xml file is stored, and I'm hesitant to just split module_name at the dots and just use the first part, as it somehow "doesn't feel right". The whole thing somehow seems overly complicated, given that I'm implementing it in Python, so maybe I'm artificially complicating things. If someone could provide some insights or simplify my plugin scheme, I would really appreciate it. Cheers, Celvin

1 0

specifying a requirement on multiple setuptools extras
by Chris Withers Dec. 3, 2009

Dec. 3, 2009

Hi All, Say I have a package, mortar, that offers multiple extras options for different data storage mechanisms, eg: sqlalchemy, zodb, simpledb If I want to use this in a project and want both the sqlalchemy and zodb backends, how do I spell this? easy_install mortar[sqlalchemy,zodb] easy_install mortar[sqlalchemy] easy_install mortar[zodb] ...or something else? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

2 2