Mailman 3 January 2009 - Distutils-SIG

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

23 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 21 Jan '09

21 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