Mailman 3 January 2009 - Distutils-SIG

Zip-safe way of detecting plugins?
by Arve Knudsen 29 Jan '09

29 Jan '09

What's the safe way of detecting plugins in a package that is potentially zipped? Thanks, Arve

1 0

[ANN] stdeb 0.2.2 released
by Andrew Straw 29 Jan '09

29 Jan '09

stdeb ("setuptools debian") produces Debian source packages from Python packages via a new distutils command, sdist_dsc. Automatic defaults are provided for the Debian package, but many aspects of the resulting package can be customized via a configuration file. This new release, 0.2.2, adds optional automatic dependency finding from Zooko O'Whielacronx. Additionally, I have moved development to github. The homepage: http://github.com/astraw/stdeb Download: http://pypi.python.org/pypi/stdeb/0.2.2 Thanks and enjoy, Andrew

1 0

announcing setuptools_trial -- a setuptools plugin to run unit tests with trial
by zooko 28 Jan '09

28 Jan '09

Hey folks, if you use setuptools to build your project and you want to use Twisted trial to run the unit tests, just install setuptools_trial and run "python ./setup.py trial": http://pypi.python.org/pypi/setuptools_trial Thanks to Chris Galvan and the folks from the Elisa project. Regards, Zooko

1 0

including an empty directory
by Domen Kožar 28 Jan '09

28 Jan '09

I'm having issues to include an empty directory to setuptools package. package_data={'data':['templates/*tmpl']} this includes all the files, but there is data/templates/Test directory that is empty and there is no way of globing it.

5 10

Anyone interested in updating/reoriganizing distutils pages on wiki.python.org?
by Akira Kitada 25 Jan '09

25 Jan '09

Hi, I'm planning to reorganize distutils pages on wiki.python.org. Before I begin, I would like to know if there are anyone interested in working on this. My goals are: - Collect distutils information into one place - One top page and sub pages - Update contents of distutils page. - Have a link to distutils top page on the wiki. - etc, etc. If there is anyone interested in this, please reply this mail.

2 2

Re: [Distutils] easy_install with python 2.4 and 2.5 installed
by Phillip J. Eby 24 Jan '09

24 Jan '09

At 05:50 PM 1/23/2009, fred basset wrote: >Hi All, > >My Fedora machine has python 2.5 installed, but I needed to install >Python 2.4 on it for TurboGears. TurboGears needs some extra >libraries such as pytz, sqlalchem. >How can I use easy_install to install those libraries for python 2.4 >only? Easy_install is already setup on my machine for python 2.5 python2.4 -m easy_install or: easy_install-2.4

1 0

easy_install with python 2.4 and 2.5 installed
by fred basset 23 Jan '09

23 Jan '09

Hi All, My Fedora machine has python 2.5 installed, but I needed to install Python 2.4 on it for TurboGears. TurboGears needs some extra libraries such as pytz, sqlalchem. How can I use easy_install to install those libraries for python 2.4 only? Easy_install is already setup on my machine for python 2.5 Thanks, Fred

1 0

Properly handle username/password for subversion
by Patrice Neff 23 Jan '09

23 Jan '09

Hi, In the online documentations of EasyInstall I read about the username/ password syntax: <http://peak.telecommunity.com/DevCenter/EasyInstall#password-protected-sites >. I was then surprised to find that this does not work for links to Subversion repositories. That's important to us as we deploy all our development snapshots from Subversion directly. For the time being I have worked around the problem by deploying the ~/.subversion/auth directory to our servers. But I was still interested in a proper fix. May I suggest the patch which I uploaded on <http://paste.pocoo.org/show/100934/>? Patrice Neff

1 0

Path problem with zope.testing and buildout
by Barry Warsaw 22 Jan '09

22 Jan '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm not entirely sure this is the right place to report this problem, but I'll give it a shot anyway. I'm sure this is pebkac but I haven't figure it out yet. My current Mailman 3 code is buildout-based. The branch is here: https://code.launchpad.net/~mailman-coders/mailman/3.0 Here's my buildout.cfg file: - -----snip snip----- [buildout] parts = interpreter tags test unzip = true develop = . [interpreter] recipe = zc.recipe.egg interpreter = py eggs = lazr.config lazr.delegates locknix mailman munepy storm zope.interface [tags] recipe = z3c.recipe.tag:tags eggs = mailman [test] recipe = zc.recipe.testrunner eggs = mailman defaults = '--tests-pattern ^tests --exit-with-status'.split() # Hack in extra arguments to zope.testrunner. initialization = from mailman.testing.layers import ConfigLayer; ConfigLayer.hack_options_parser() - -----snip snip----- If I build this out and then run bin/test, my test suite passes, but I get ImportErrors for every dependent egg that gets downloaded. It's as if the eggs directory is being search for tests even though eggs=mailman is in the [test] section. However, if I put the following in my ~/.buildout/default.cfg, I don't those ImportErrors, presumably because the eggs are so far distant that Zope's testrunner doesn't find them. - -----snip snip----- [buildout] eggs-directory=/Users/barry/.buildout/eggs download-cache=/Users/barry/.buildout/download-cache - -----snip snip----- Here's an excerpt from the bin/test output (with extra blank lines suppressed): Test-module import failures: Module: eggs.lazr.config-1.1-py2.6.egg.lazr.config.tests ImportError: No module named eggs.lazr.config-1.1- py2.6.egg.lazr.config.tests Module: eggs.lazr.delegates-1.0-py2.6.egg.lazr.delegates.tests ImportError: No module named eggs.lazr.delegates-1.0- py2.6.egg.lazr.delegates.tests Module: eggs.zc.buildout-1.1.1-py2.6.egg.zc.buildout.tests ImportError: No module named eggs.zc.buildout-1.1.1- py2.6.egg.zc.buildout.tests Module: eggs.zc.buildout-1.1.1-py2.6.egg.zc.buildout.testselectingpython ImportError: No module named eggs.zc.buildout-1.1.1- py2.6.egg.zc.buildout.testselectingpython Module: eggs.zc.recipe.egg-1.1.0-py2.6.egg.zc.recipe.egg.tests ImportError: No module named eggs.zc.recipe.egg-1.1.0- py2.6.egg.zc.recipe.egg.tests Module: eggs.zc.recipe.testrunner-1.1.0- py2.6.egg.zc.recipe.testrunner.tests ImportError: No module named eggs.zc.recipe.testrunner-1.1.0- py2.6.egg.zc.recipe.testrunner.tests Module: eggs.zope.interface-3.5.0-py2.6-macosx-10.3- i386.egg.zope.interface.common.tests.test_idatetime ImportError: No module named eggs.zope.interface-3.5.0-py2.6- macosx-10.3-i386.egg.zope.interface.common.tests.test_idatetime Module: eggs.zope.interface-3.5.0-py2.6-macosx-10.3- i386.egg.zope.interface.common.tests.test_import_interfaces ImportError: No module named eggs.zope.interface-3.5.0-py2.6- macosx-10.3-i386.egg.zope.interface.common.tests.test_import_interfaces Module: eggs.zope.interface-3.5.0-py2.6-macosx-10.3- i386.egg.zope.interface.tests.test_adapter ImportError: No module named eggs.zope.interface-3.5.0-py2.6- macosx-10.3-i386.egg.zope.interface.tests.test_adapter Module: eggs.zope.interface-3.5.0-py2.6-macosx-10.3- i386.egg.zope.interface.tests.test_advice ImportError: No module named eggs.zope.interface-3.5.0-py2.6- macosx-10.3-i386.egg.zope.interface.tests.test_advice Module: eggs.zope.interface-3.5.0-py2.6-macosx-10.3- i386.egg.zope.interface.tests.test_declarations ImportError: No module named eggs.zope.interface-3.5.0-py2.6- macosx-10.3-i386.egg.zope.interface.tests.test_declarations Module: eggs.zope.interface-3.5.0-py2.6-macosx-10.3- i386.egg.zope.interface.tests.test_document ImportError: No module named eggs.zope.interface-3.5.0-py2.6- macosx-10.3-i386.egg.zope.interface.tests.test_document Module: eggs.zope.interface-3.5.0-py2.6-macosx-10.3- i386.egg.zope.interface.tests.test_element ImportError: No module named eggs.zope.interface-3.5.0-py2.6- macosx-10.3-i386.egg.zope.interface.tests.test_element Module: eggs.zope.interface-3.5.0-py2.6-macosx-10.3- i386.egg.zope.interface.tests.test_interface ImportError: No module named eggs.zope.interface-3.5.0-py2.6- macosx-10.3-i386.egg.zope.interface.tests.test_interface Module: eggs.zope.interface-3.5.0-py2.6-macosx-10.3- i386.egg.zope.interface.tests.test_odd_declarations ImportError: No module named eggs.zope.interface-3.5.0-py2.6- macosx-10.3-i386.egg.zope.interface.tests.test_odd_declarations Module: eggs.zope.interface-3.5.0-py2.6-macosx-10.3- i386.egg.zope.interface.tests.test_sorting ImportError: No module named eggs.zope.interface-3.5.0-py2.6- macosx-10.3-i386.egg.zope.interface.tests.test_sorting Module: eggs.zope.interface-3.5.0-py2.6-macosx-10.3- i386.egg.zope.interface.tests.test_verify ImportError: No module named eggs.zope.interface-3.5.0-py2.6- macosx-10.3-i386.egg.zope.interface.tests.test_verify Module: eggs.zope.testing-3.7.1-py2.6.egg.zope.testing.tests ImportError: No module named eggs.zope.testing-3.7.1- py2.6.egg.zope.testing.tests Module: eggs.zope.testing-3.7.1-py2.6.egg.zope.testing.testrunner.tests ImportError: No module named eggs.zope.testing-3.7.1- py2.6.egg.zope.testing.testrunner.tests The same behavior occurs on Linux. Does anybody have any suggestions for making bin/test work without putting your eggs outside the source tree? Or if it's not possible, I'll update my README.txt to explain that you have to have a ~/.buildout/default.cfg. Thanks, Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSXacqnEjvBPtnXfVAQIfoQP+NmPMyOlky4rqSF9UWF/cOi4K/G++YYRO DodibIMefqhoX+2SEjfavm9NN9nIVt0Wrvaty0acnZ1FHc7pPwN+szUV6is1QAao Q7WQbZyQewPVk+3tucuBD7UtcMoBpHScq4afL4u4crSozf3DpVI0YwqhYf4hvvo8 XrFTINdDfCI= =E5eP -----END PGP SIGNATURE-----

2 2

Extending distutils with a package in site-packages?
by Akira Kitada 21 Jan '09

21 Jan '09

Hi, I'm trying to write a module 'mydistutils', an extension to original distutils. I would like to make it distutils-compatible so that user of the module use mydistutils interchangeably. The only difference between them would be the addition of 'MyDistribution' and 'bdist_mycmd'. Because I don't want to mess up my python installation, It want to put all of those extension parts in site-packages/. But if I do that way, I cannot do "from mydistutils import core" or the like because mydistutils is in different package... Is there any pythonic tips for dealing this problem? I'd like to keep it simple, so setuptools-free solution would be preferable Thanks,

2 2

Re: [Distutils] get_metadata in Distutils
by Phillip J. Eby 21 Jan '09

21 Jan '09

At 11:24 AM 1/15/2009 +0100, Tarek Ziadé wrote: >On Mon, Jan 12, 2009 at 5:07 PM, Phillip J. Eby <pje(a)telecommunity.com> wrote: > > At 02:11 PM 1/12/2009 +0100, Tarek Ziadé wrote: > >> > >> Ok, I will introduce in my patch the other formats. I am wondering though, > >> how > >> far this would be from an integration of pkg_resources into > >> Distutils/pkgutil, > >> with some API on the top and if it makes sense. > > > > It makes sense to me, I just wanted you to be aware how deep a job it is. > > You're probably going to need a generic function by importer type, just > > like the others in pkgutil. > >I am making some progress, now the patch works with zipped eggs, unzipped eggs >and regular .egg-info files. > >I am wondering about other cases though: > >- it seems that pkg_resources works on .egg-info *directories*. When >does this case happen ? System packages (.rpm, .deb, etc.), or other install --root/--single-version-externally-managed installs of setuptools-based packages. (Of course, there are also .egg directories with EGG-INFO subdirectories, installed by easy_install --always-unzip...) >- you said that its needs to work on nested packages, but I can't see >the difference when grabbing the metadata in such a package More precisely: you can have nested .egg directories within a single zipfile. This is to support bundling a bunch of eggs in a single zipfile for easy application distribution. >There are also some mechanisms I am not sure at a 100% of, like the >right way to loop over sys.path entries, and the way to deal with >sys.meta_path, etc.. Well, setuptools ignores sys.meta_path, but I suppose technically it shouldn't. A use case hasn't occurred yet, though, at least to my knowledge.

2 1

[zc.buildout] borrowing another part's eggs
by Pascoe, S (Stephen) 21 Jan '09

21 Jan '09

Is there a way for a recipe to pick another part's dependencies so that it can do the sys.path[0:0] = [...] magic that zc.buildout.easy_install.scripts does. I'm trying to add functionality to a zc.recipe.egg buildout by writing a recipe but I'm finding I want to use the working_set configured in the zc.recipe.egg part. E.g. """ [buildout] develop-eggs = recipes parts = foo bar [foo] recipe = zc.recipe.egg eggs = ... [bar] recipe = recipes:myrecipe # I want to create scripts that include the eggs installed in foo eggs_from = foo ... """ At the moment the only option I can see is: 1. Grab config options from the [foo] section and re-parse all options relating to egg configuration (eggs/dependency-links/etc.) 2. Call zc.recipe.easy_install.install() to get a working set. 3. Write sys.path[0:0] = [...] into my scripts based on the new working set. It seems a little redundant but the zc.buildout.easy_install.scripts API doesn't quite do what I want. Thanks, Stephen. --- Stephen Pascoe +44 (0)1235 445980 British Atmospheric Data Centre Rutherford Appleton Laboratory -- Scanned by iCritical.

2 1

let's have a new release of stdeb!
by zooko 20 Jan '09

20 Jan '09

Folks: We've finally gotten the build/test/install process of allmydata.org tahoe working smoothly using setuptools. (Thanks especially to Chris Galvan.) See our buildbot for many details: http://allmydata.org/buildbot/waterfall?show_events=true Here is the list of dependencies which are automatically satisfied by setuptools. (This list is taken from our Ubuntu Dapper buildslave.) allmydata-tahoe: 1.2.0-r3452, foolscap: 0.3.2, pycryptopp: 0.5.12, zfec: 1.4.4, Twisted: 8.2.0, Nevow: 0.9.32, zope.interface: 3.5.0, simplejson: 2.0.7, argparse: 0.8.0, pyOpenSSL: 0.8, pyutil: 1.3.30, zbase32: 1.1.1, setuptools: 0.6c10dev For reference, a year ago many of these couldn't be correctly installed by setuptools. The next step that I would like to take is to automate the production of .deb's from setup.py's. The stdeb tool works fairly well for this. I would be especially pleased if Andrew Straw and Pedro Algarvio, the maintainers of stdeb, would release a new version including the patch that I submitted to automatically detect debian dependencies from setuptools dependencies, using apt-listfiles: https://code.launchpad.net/~astraw/stdeb/autofind-depends I just looked at the stdeb home page: http://stdeb.python-hosting.com and it said: """ Call for volunteers I don't have a lot of time for this. This project stands a very real chance of being only a shadow of its potential self unless people step up and contribute. There are numerous ways in which people could help. In particular, I'd be interested in finding a co-maintainer or maintainer if the project generates any interest. Secondarily, I would appreciate advice from Debian developers or Ubuntu MOTUs about the arcane details of Python packaging. Please address all questions to the distutils-SIG """ So, how about it? Regards, Zooko --- Tahoe, the Least-Authority Filesystem -- http://allmydata.org store your data: $10/month -- http://allmydata.com/?tracking=zsig

1 0

[issue57] develop doesn't create .pth files and site.py if --multi-version
by Zooko O'Whielacronx 20 Jan '09

20 Jan '09

New submission from Zooko O'Whielacronx <zooko(a)zooko.com>: The allmydata.org tahoe-lafs project uses "./setup.py develop" to build. We have started having problems with older versions of dependencies already being installed, so we want to add "--multi-version" to the "./setup.py develop" command, but when we do some parts of our build system break. Investigation shows that the only difference in the resulting filesystem between "setup.py develop --multi-version --prefix=support", as shown here: http://allmydata.org/buildbot/builders/cygwin/builds/1676/steps/install/log… and "setup.py develop --prefix=support", as shown here: http://allmydata.org/buildbot/builders/cygwin/builds/1685/steps/build_tahoe… Is that in the former case, the "easy-install.pth", "setuptools.pth", and "site.py" files are not created in the target directory "support". Is this intended? Without those files, the subsequent attempt to use pkg_resources (which is installed as an install_requirement) fails: http://allmydata.org/buildbot/builders/cygwin/builds/1676/steps/tahoe-versi… ---------- messages: 228 nosy: zooko priority: bug status: unread title: develop doesn't create .pth files and site.py if --multi-version _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue57> _______________________________________________

1 0

Problems installing Easy Install/Setup Tools (segmentation fault)
by Niklas Bivald 20 Jan '09

20 Jan '09

Dear peak, I've been tearing my hair out on a installation issue I've been having. I've searched Google, I've searched the archives. I've been running setuptools on my OS X box for quite a while and it's been working great. However, moving on to my Debian (production) box has cause me considerable problems. It may be a Python issue, but I've tried Python 2.4, 2.5 and 2.6 (and 2.6.1) and I keep getting the same error. Hopefully I've just missed something easy. I've tried to install setuptools using apt-get without luck (gives me a non-describt error about failed installation) and using eggs: chat4:/home/orbited# sh setuptools-0.6c9-py2.6.egg Segmentation fault gives me segmentation fault. I've switched to using from source in order to catch the exact error, and I've boiled it down to: chat4:/home/orbited/setuptools-0.6c9# python2.6 -dv easy_install.py install [...] Quite a long output [...] # /home/orbited/setuptools-0.6c9/setuptools/dist.pyc matches /home/ orbited/setuptools-0.6c9/setuptools/dist.py import setuptools.dist # precompiled from /home/orbited/ setuptools-0.6c9/setuptools/dist.pyc Segmentation fault On Python2.6, 2.5 and 2.4. Verifying the problem on 2.5: chat4:/home/orbited/setuptools-0.6c9# python Python 2.5.2 (r252:60911, Jan 4 2009, 17:40:26) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import setuptools.dist Segmentation fault On 2.6: chat4:/home/orbited/setuptools-0.6c9# python2.6 Python 2.6.1 (r261:67515, Jan 20 2009, 07:59:19) [GCC 4.3.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import setuptools.dist Segmentation fault I must be missing something vital, using more debug flags gives me: import setuptools.dist # precompiled from /home/orbited/ setuptools-0.6c9/setuptools/dist.pyc # trying /home/orbited/setuptools-0.6c9/setuptools/depends.so # trying /home/orbited/setuptools-0.6c9/setuptools/dependsmodule.so # trying /home/orbited/setuptools-0.6c9/setuptools/depends.py Segmentation fault Can anyone think of anything that would share some light on this issue? Regards, Niklas

3 2

Building Python Eggs
by Amit k. Saha 20 Jan '09

20 Jan '09

Hi all, I am just learning the basics of building Python eggs using 'setuptools'. What I have is the following code structure in a top-down fashion: - demo1.py - __init.py__ - setup.py -subpackage1 --__init.py/__ When I execute 'python setup.py bdist_egg' from the top-level directory which has the 'setup.py' file: __author__="amit" __date__ ="$14 Jan, 2009 2:37:34 PM$" from setuptools import setup,find_packages setup ( name = 'EggDemo', version = '0.1', Summary = 'Just another Python package for the cheese shop', author = 'amit', author_email = '', url = '', license = '', description= 'Long description of the package', platform= '', packages = find_packages(), ) In the resulting, SOURCES.txt file, I have: setup.py EggDemo.egg-info/PKG-INFO EggDemo.egg-info/SOURCES.txt EggDemo.egg-info/dependency_links.txt EggDemo.egg-info/top_level.txt subpackage1/__init__.py As you can see, the top-level 'demo1.py' is missing, even though I have a '__init.py__' file there. The manual at http://peak.telecommunity.com/DevCenter/setuptools#using-find-packages makes me believe, this should work. Where am I going wrong? Best, Amit -- Amit Kumar Saha http://amitksaha.blogspot.com http://amitsaha.in.googlepages.com/ *Bangalore Open Java Users Group*:http:www.bojug.in

5 7

Where to put a original distutils command?
by Akira Kitada 20 Jan '09

20 Jan '09

Hi, I was wondering where I'm supposed to put a new distutils command in. The command is a kind of bdist_rpm-like thing for my own package system, so it's just for local use so won't ever move in Python distribution. I thought site-packages, but just for one command, it would be a bit overkill. Any ideas?

2 1

The latest stable standalone Distutils?
by Akira Kitada 18 Jan '09

18 Jan '09

Hello, I've just read distutils/README [1] which says there's "a separately packaged standalone version of the Distutils" on Distutils web page [2]. It seems, however, this is just a unmaintained README and actually all I could find there was old "Distutils-1.0.2". Where can I find the latest standalone Distutils? I looked at projects/distutils on svn.python.org but it didn't appear to be maintained. Thanks in advance, [1] http://svn.python.org/view/python/trunk/Lib/distutils/README [2] http://www.python.org/sigs/distutils-sig/

2 3

Re: [Distutils] custom package index issue
by Phillip J. Eby 15 Jan '09

15 Jan '09

At 02:44 PM 1/15/2009 +0100, Eric Lemoine wrote: >Hi > >For a project I'm involved in we created our own package index. The >package index includes our package (mapfish), as well as its direct >and indirect dependencies. > >Then, the installation of the "mapfish" package and its dependencies >is done with this command: >easy_install -i http://dev.camptocamp.com/packages/mapfish/1.0/index >mapfish==1.0 > >The installation command works, but some indirect dependencies aren't >downloaded from our package index but from other sources. For >example,"simplejson" which "pylons" depends on (which "mapfish" >depends on), is downloaded from >"http://pylons.cachefly.net/download/0.9.6.2/simplejson-1.7.1-py2.5.egg" >as opposed to be downloaded from >"http://dev.camptocamp.com/packages/mapfish/1.0/simplejson-1.7.1.tar.gz". Binary packages are given precedence over source packages, and presumably Pylons is providing a direct link in its setup.py. >We'd like every mapfish dependency to be downloaded from our package >index. Does anyone know how to achieve this? You'll need to either ensure that your index provides binaries, or use --allow-hosts to restrict what hosts easy_install will look for files on.

4 3

custom package index issue
by Eric Lemoine 15 Jan '09

15 Jan '09

Hi For a project I'm involved in we created our own package index. The package index includes our package (mapfish), as well as its direct and indirect dependencies. Then, the installation of the "mapfish" package and its dependencies is done with this command: easy_install -i http://dev.camptocamp.com/packages/mapfish/1.0/index mapfish==1.0 The installation command works, but some indirect dependencies aren't downloaded from our package index but from other sources. For example,"simplejson" which "pylons" depends on (which "mapfish" depends on), is downloaded from "http://pylons.cachefly.net/download/0.9.6.2/simplejson-1.7.1-py2.5.egg" as opposed to be downloaded from "http://dev.camptocamp.com/packages/mapfish/1.0/simplejson-1.7.1.tar.gz". We'd like every mapfish dependency to be downloaded from our package index. Does anyone know how to achieve this? Thanks a lot, -- Eric

2 1

buildout recipe options
by dunia 15 Jan '09

15 Jan '09

Hi list I'm a little bit confused with the buildout configuration files, and i can't find any useful information. I get that every part of the buildout has a recipe and this recipe takes some configuration options. My question is ...how can i know which are those options? I went through the code and found most of them, but not all. For example, since i'm running on Debian i would like to use buildout + dzhandle, so i need plone.recipe.dzhandle. I found some configuration options used explicitly in the code (locationtype, location, zopetype, version, zope2-location, zopeuser, zcml, serviceuser and instancename), but i also found in an example buildout configuration file «httpport» (obvious what it is used for) and «threads» (not that obvious for me :) ). Also i would like to know which other options i can use to set, for instance, dzhandle «--addon-mode» that is mandatory when using dzhandle alone. Maybe this is very simple, i recognize that my knowledge of python is not as good as it should be...yet ;). Anyways, any hint would be useful for me. My english is not very good :(, my apologies. Thanks & happy new year! :)

6 6

Re: [Distutils] get_metadata in Distutils
by Phillip J. Eby 15 Jan '09

15 Jan '09

At 02:11 PM 1/12/2009 +0100, Tarek Ziadé wrote: >Ok, I will introduce in my patch the other formats. I am wondering though, how >far this would be from an integration of pkg_resources into Distutils/pkgutil, >with some API on the top and if it makes sense. It makes sense to me, I just wanted you to be aware how deep a job it is. You're probably going to need a generic function by importer type, just like the others in pkgutil. >The only difference I can see is that I am working on an API that would return >DistributionMetadata instances > >http://bugs.python.org/file12692/get_metadata.diff Yep... which means that you're going to have to reinvent (and re-test) a fair number of wheels to get there. pkg_resources just lets you ask for a distribution's PKG-INFO metadata, and get it back as a string, regardless of what egg format is in use (including distutils). But to *just* support PKG-INFO, the irony is that you'll have to recreate a fair amount of stuff. >I'd say then : if setutpools version parsing system is superior to >distutils.versionpredicate, I'm not actually familiar with "versionpredicate", so I couldn't say. It's definitely superior to LooseVersion and StrictVersion, which were the only version tools available in the distutils when I started all this. >wouldn't it make sense to merge it into Distutils ? > >Maybe that was the initial plans ? Yes, and yes. Setuptools version parsing (and name/version escaping) functions at least doesn't have any dependencies on anything else. So that's an easy port. If you want Requirement objects as well (specifying various version ranges), a bit more gets pulled in. However, if all you want is to be able to turn versions into opaquely-comparable values, parse_version() and its dependencies are all you need. (By the way, I previously proposed PEP 365 -- that pkg_resources simply be bundled in the stdlib -- to address these needs.) >Well, being able to query the installed version for a package seem to >me like a feature >that should live in Distutils or pkgutil > >In the same way, being able to do version arithmetic is rather >important, and it would be better >ihmo to have one and only one way to deal with that in Python, > >What are you plans for Setuptools development for the future ? I hope someday to have some time for it again. :)

2 1

Re: [Distutils] Changing distribution versions runtime
by Phillip J. Eby 14 Jan '09

14 Jan '09

At 01:52 PM 1/14/2009 +0200, bl8cki wrote: >To avoid removing added things in working_set ... i remove the entry >for which i need to switch versions in easy-install.pth and then >only 'resolve'-ing and 'add'-ing to the working_set. > >I don't know if this (removing the lines in easy-install.pth) will >reflect on easy_install to work properly, but for now i'm happy with >this solution :) > >Still will be very thankful for any comments and suggestions. "easy_install -m projectname" will remove the line for you. For that matter, using -m when you install those eggs in the first place will also do the trick.

1 0

Changing distribution versions runtime
by bl8cki 14 Jan '09

14 Jan '09

Hello all, I would like at runtime to change the used version of installed egg ... (for example based on some condition import specific version) and the only solution i end up with is to remove from the 'working_set' 'by_key' hash the best matched version, added when importing pkg_resources, and then 'resolve' the wished one and add it. otherwise i end up with version conflict. I do not want to add version in package naming (package_0_1) ... but that would be the fastest solution :) What's the best thing i can do? Thanks!

1 1

Re: [Distutils] get_metadata in Distutils
by Phillip J. Eby 12 Jan '09

12 Jan '09

At 08:22 PM 1/11/2009 +0100, Tarek Ziadé wrote: >On Sat, Jan 10, 2009 at 9:09 PM, Phillip J. Eby <pje(a)telecommunity.com> wrote: > >> > >> Since this is basically what has been done in setuptools, I thaught > >> that you might wanted to help around for this change ? > > > > I'd suggest looking at the pkg_resources code, particularly > > find_distributions and its related functions. > >Ok thanks, > > > Note, for example, that egg > > layouts can be nested (even when zipped!), and that the metadata can have > > different filenames, depending on the installation format. > >This is my understanding at this stage : > From a Distutils point of view, it seems that this would suffice to >read the metadata from the egg-info files : > >1/ add in distutils.dist.DistributionMetadata a new method to be able >to load an existing egg-info file >2/ add in the pkgutil module, the get_metadata function, that could >have this signature: > > get_metadata(package_name, path_item) > >where path_item is a site-packages like directory, > >this function would scan the path_item directory, like what >setuptools.pkg_resource code does, >and return the metadata (+fill a cache with all packages metadata found) My point was that if you don't support .egg files or EGG-INFO/PKG-INFO, then your API is rather crippled; there is no reason for anyone using setuptools to use it in place of the corresponding pkg_resources API, as it simply will not work with packages installed by easy_install. > > Version parsing > > also has certain peculiarities, which also means that people doing simple > > string comparisons on the version field is probably not going to suffice. > >Wouldn't distutils.versionpredicate be useful here ? Only if the package in question follows distutils' rules, which aren't as flexible as those of setuptools... and setuptools' version parsing system was designed to handle a significant number of versioning schemes that were in use on PyPI at the time -- schemes that the distutils mostly couldn't parse correctly. I'm just trying to warn you that adding these features in a distutils-only way could easily end up like the PKG-INFO "requires" and "provides" fields -- that is, theoretically useful but of no practical value to anyone. In fact, they could be "attractive nuisances" in that they would encourage people to use them, only to find out later that it was a complete dead end because of the lack of support for anything but pure-distutils packages. Of course, they will then blame me and setuptools rather than you and the distutils, but I suppose I'm used to that. ;-)

2 1