Mailman 3 March 2007 - Distutils-SIG

Improved error handling in zc.buildout
by Jim Fulton 19 Mar '07

19 Mar '07

A major annoyance in zc.buildout has been its poor error handling. Generally, when an error occurred, a a traceback would be printed giving little or no clue about what went wrong or what was going on. Previously, I was focussed on important features. The latest release focusses on better error reporting and debugging support. I'd like to continue to provide some emphasis on this, so feedback would be especially appreciated now that I think I've improved error handling quite a bit. 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

3 4

pakage index __getitem__
by Jim Fulton 18 Mar '07

18 Mar '07

I want to get a list of all of the distributions I can find that satisfy a requirement. I've found the following works: index.obtain(requirement) dists = [d for d in index[requirement.project_name] if d in requirement] where index is a setuptools.package_index.PackageIndex. Is there a better way? The obtain call seems to be necessary to initialize the index for the given project. 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

Buildout configurations in a subdirectory stopped working.
by Lennart Regebro 17 Mar '07

17 Mar '07

On 2/19/07, Christian Theune <ct(a)gocept.com> wrote: > [buildout] > extends = profiles/dev.cfg > > and run bin/buildout. > > This works very well for us. It did for me too, but it has now stopped working. Line 89 in buildout.py says: data['buildout']['directory'] = os.path.dirname(config_file) This must be a recent change (< 2 weeks) because this makes buildout fail if you have the cfg files anywhere else than root. I'd like to know the rationale for this change, as I'd like to be able to have the profiles in a subdirectory. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64

2 2

Re: [Distutils] restructured text formatting not present in generated MS Windows binary installer
by Thomas Heller 16 Mar '07

16 Mar '07

[Add CC to distutils-sig again] >> Jim Vickroy schrieb: >> >>> Hello, >>> >>> I have been unsuccessful in using restructured text formatting tags in >>> the long_description parameter for the distutils.core.setup function. >>> >>> When the attached "setup" script (see GOES-13-SXI-processor-installer.py >>> attachment) is run from the command line as: >>> >>> > GOES-13-SXI-processor-installer.py clean bdist_wininst --title="FITS >>> Images Processor" --bitmap=GOES-13-SXI-Processor.bmp >>> >>> the first panel of the generated win32 installer has no boldface text >>> (see installer.png attachment) >>> >>> When I feed the long_description text to docutils/tools/rst2html.py, the >>> generated html is as expected. >>> Jim Vickroy schrieb: > Thanks much, Thomas. > > I think this piece of wisdom would be useful to add to the distutils > document, or is that limitation obvious to everyone but me? Well, you're the first one to ask this question ;-). I have no idea where you got the impression from that using rest in the long_description should give visual markup in the bdist_wininst installer. Maybe that would be the place where a hint like 'distutils does not interpret rest' would be usefull. Thomas

2 1

restructured text formatting not present in generated MS Windows binary installer
by Jim Vickroy 16 Mar '07

16 Mar '07

Hello, I have been unsuccessful in using restructured text formatting tags in the long_description parameter for the distutils.core.setup function. When the attached "setup" script (see GOES-13-SXI-processor-installer.py attachment) is run from the command line as: > GOES-13-SXI-processor-installer.py clean bdist_wininst --title="FITS Images Processor" --bitmap=GOES-13-SXI-Processor.bmp the first panel of the generated win32 installer has no boldface text (see installer.png attachment) When I feed the long_description text to docutils/tools/rst2html.py, the generated html is as expected. My setup is: Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import docutils >>> docutils.__version__ '0.5' >>> on a MS Windows XP machine running service pack 2. I am a new user of both distutils and docutils so any thoughts on what I am doing incorrectly would be appreciated. Thanks, -- jv

2 1

Re: [Distutils] Getting an egg's version: better way?
by Phillip J. Eby 16 Mar '07

16 Mar '07

At 10:48 AM 3/15/2007 -0400, Nathan R. Yergler wrote: >I have a situation where I want to get the version of an egg that's >installed. I figured out the following, but wanted to know if I'm >missing something obvious that's easier:: > > >>> import pkg_resources > >>> p = pkg_resources.get_provider("cctagutils") > >>> for line in p.get_metadata_lines("PKG-INFO"): > ... if line.find('Version: ') == 0: > ... version = line.split()[-1] The problem with using get_provider() and a module name, is that it cannot conclusively associate a package with a specific project. Thus, your code above has a bug: it will not find a version of a package that's installed by a system packaging tool such as RPM, or a bdist .exe or .msi on Windows. You need to use a project name instead of a package/module name, e.g.: version = pkg_resources.require('ProjectNameHere')[0].version This will work even with projects installed using system packaging tools, as it explicitly indicates what project's PKG-INFO will be read, if in fact it needs to be read at all. (In most cases, pkg_resources will get the project's version number from a filename, without needing to open any files.)

2 1

Visual Studio 2005 changes
by Howard Lightstone 16 Mar '07

16 Mar '07

I have some (minor ?) changes to msvccompiler.py to support VC8 (and embedding manifests). Where should I submit these changes for someone (knowledgable) to review?

2 1

Getting an egg's version: better way?
by Nathan R. Yergler 15 Mar '07

15 Mar '07

I have a situation where I want to get the version of an egg that's installed. I figured out the following, but wanted to know if I'm missing something obvious that's easier:: >>> import pkg_resources >>> p = pkg_resources.get_provider("cctagutils") >>> for line in p.get_metadata_lines("PKG-INFO"): ... if line.find('Version: ') == 0: ... version = line.split()[-1] Thanks, Nathan

2 1

Re: [Distutils] Buildout install command
by Scott Robertson 12 Mar '07

12 Mar '07

Ok slightly confused, (hope I'm not wasting your time with this Jim) I just checked that url you provided. There is no mention of the "install" command, which I found by running buildout --help. Here's the text: Commands: install [parts] Install parts. If no command arguments are given, then the parts definition from the configuration file is used. Otherwise, the arguments specify the parts to be installed. Interestingly (i.e. what confuses me) If I run $ buildout buildout:parts = part1 Part 1 is built and all of part1's dependencies. However if I run $ buildout install part1 Part 1 starts to build but in my case bombs because part 1's dependencies aren't built. So as a new buildout user I'm confused about: 1. The purpose of the install command 2. Why it doesn't build dependencies. On 3/12/07, Jim Fulton <jim(a)zope.com> wrote: > > On Mar 12, 2007, at 12:40 PM, Scott Robertson wrote: > > > Thanks Jim, > > I stumbled upon that myself this weekend wasn't sure if it was > > appropriate. > > > > One thing I noticed, is that if you use the "install" keyword on the > > command line i.e. > > $ buildout install some-section > > > > Dependent sections don't get built (is that intentional?) > > Yes, and documented (http://www.python.org/pypi/zc.buildout#command- > line-usage). > > If you want to install a part and its dependents, use: > buildout:installed=partname, > or, for multiple parts: "buildout:installed=p1 p2 p3". > > 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 > > > >

1 0

Buildout question
by Scott Robertson 12 Mar '07

12 Mar '07

Is there a way to create a dummy part/recipe that depends on another part without having to refer to one of the options of other part? Similar to make's concept of a phony target I suppose. I'm looking to make a buildout script that looks something like this: [buildout] parts = all [all] recipe=depends parts = linux win32 mac [linux] recipe=depends parts=common-part linux-specific-part [win32] recipe=depends parts=common-part win32-specific-part-1 win32-specific-part-2 [mac] recipe=depends parts=common-part mac-specific-part ... real part specifications would follow ... So as you can see, I'm trying to make a buildout script that will build three different variations of the same project for the three major platforms Windows, Mac and Linux from the same build machine. Depending on the platform I'm building for I may build parts in my buildout file. Ideally from the command line I'd like to do something like this. $ buildout install linux or $ buildout install mac or $ buildout install win32 or $ buildout install all Is this possible to do in recipe or is there some other mechanism I could use to do this dependency? The refering to a variable of another part sort of works for this, but I think it would be easier to read (and less typing) if I could epxlicitly declare that a given part depends on another.

2 3