Mailman 3 January 2009 - Distutils-SIG

Building Python Eggs
by Amit k. Saha Jan. 20, 2009

Jan. 20, 2009

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 Jan. 20, 2009

Jan. 20, 2009

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 Jan. 18, 2009

Jan. 18, 2009

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 Jan. 15, 2009

Jan. 15, 2009

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 Jan. 15, 2009

Jan. 15, 2009

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 Jan. 15, 2009

Jan. 15, 2009

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 Jan. 15, 2009

Jan. 15, 2009

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 Jan. 14, 2009

Jan. 14, 2009

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 Jan. 14, 2009

Jan. 14, 2009

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 Jan. 12, 2009

Jan. 12, 2009

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