Mailman 3 August 2010 - Distutils-SIG

Optional requirements with "extra"
by Mathieu Leduc-Hamel 11 Aug '10

11 Aug '10

Hi all, I was reading the documentation of distutils, setuptools and distribution cause I was searching for a way to add some optional dependancies to a project. In fact i would like to add an optional dependency and it will change some components of the a module. I'll explain a little bit more: I have a module called "storelocator", when you have use it without any optional dependency. In the setup script I have the following option: extras_require = { "satchmo" : ["Satchmo"], } If you install the package with the satchmo support like that: storelocator[satchmo] Then I would like be able with pkg_resources or something like to check in the code if the satchmo support has been enabled or not, if yes, i'll change some part of my package or not. Mathieu Leduc-Hamel

1 0

Announcing buildout_versions 1.2
by Chris Withers 10 Aug '10

10 Aug '10

Hi All, I'm pleased to announce a new release of buildout_versions. The new version re-shuffles the order in which un-pinned versions are reported, making it easier to spot where package dependencies come from. The PyPI page is here: http://pypi.python.org/pypi/buildout_versions The documentation is here: http://packages.python.org/buildout_versions/use.html If you have any problems or suggestions, please let me know on this list! cheers, Chris

2 2

zc.buildout: Declare options in a recipe and use it in another recipe
by Udo Spallek 10 Aug '10

10 Aug '10

Hello, like to write a custom recipe. The recipe should be able to introduce a new variable (or option) which can be used in another part of buildout.cfg. I try to catch this with the buildout.cfg and recipe attached below. The recipe is found, installed and called with part1 right before part2. So far so good. My problem is in part2. New_option is always empty and not filled with the result (testresult) in recipe test-new-option. How can I declare and transport options from one recipe script to another? Regards Udo Sample buildout.cfg [buildout] parts = part1 part2 [part1] recipe = recipes:test-new-option [part2] recipe = collective.recipe.template == 1.8 new_option = ${part1:new_option} ... ---- Recipe: test-new-option: class TestNewOption(object): """zc.buildout recipe""" def __init__(self, buildout, name, options): self.buildout, self.name, self.options = buildout, name, options def install(self): """Installer""" # Does not work: self.options['new_option'] = 'testresult' return tuple() def update(self): """Updater""" pass

4 3

GCC versions and binary egg names
by Chris Withers 06 Aug '10

06 Aug '10

Hi All, In addition to the UCS2/4 problems already described by MAL and which I've bumped into myself, I now have a problem with binary linux eggs where the GCC version doesn't match that of the system the egg is being installed on. Current egg metadata doesn't take either of these into account or even provide a way for the nature of the binary egg to be recorded. How're people coping with this? What are the future plans in this area? cheers, Chris

8 27

setuptools: 'console_scripts' does not respect 'extras' requested by easy_install?
by Sridhar Ratnakumar 05 Aug '10

05 Aug '10

From setup.py: [...] name='hello' [...] entry_points = { 'console_scripts': [ 'hello=hello:main', 'internal=hello.internal:main [secret]', [...] If I run "easy_install hello" both bin/hello and bin/internal are installed. I expected bin/internal to be installed *only* when "easy_install hello[secret]" is run. Is this anomaly a bug, or by design? I have a real-world use case for this, which is to install 'backend' scripts only when the 'backend' extras is requested. This is to prevent users from installing backend/server related commands when they only need the client commands. When creating sdist, I explicitly exclude src/hello/internal (internal packages), but there is no way to prevent the script creation other than hacking setup.py. -srid

2 1

Re: [Distutils] How to customize egg_info behavior
by P.J. Eby 04 Aug '10

04 Aug '10

At 10:36 PM 7/31/2010 -0700, Jason R. Coombs wrote: >Thanks for the tip, pje. Your suggestion was very helpful. Perhaps I can ask >a follow-up. > >In addition to calculating the tag at package-time (when setup.py is run for >sdist/bdist*), I am calculating the version at package-time. > >The problem I have with this approach is with source distributions (sdists). >Since the sdists get the same setup.py file, the calculations for version >and tag are done both at packaging time and at install time. I would like to >configure my setup.py such that when sdist is run, the version and tag are >calculated and added to the egg_info, but when a consumer of that sdist goes >to install it, the version and tag are not calculated and just consumed from >the egg_info (similar to what happens when installing a bdist_egg). When setuptools builds an sdist, it includes an updated setup.cfg containing all the original egg_info settings, so that part is done for you. What this means is that you can programmatically tell if you're running from an sdist or a checkout by looking for the tag_build setting in setup.cfg. That means that you could potentially just specify version='' in your setup(), and put the *entire* version number in the tag_build option to egg_info. In order for that to work correctly, what you'd need to do is: 1. Try to read setup.cfg using ConfigParser, and read out the 'tag_build' from the 'egg_info' section. 2. If it's found, set the version string to that, and force tag_build to an *empty string* in the options['egg_info'] passed to setup(), so that tag_build doesn't get stuck back in again (doubling-up the version). 3. If it's not found, do a straight-up calculation. The main downside to this approach, however, is that you have to put all this code in setup.py, and you can't import it from anywhere, unless you bundle the code with every project you're using it on. So here's what you do instead. Implement this as a setup() argument, e.g.: def hg_version_calc(dist, attr, value): if value: from ConfigParser import ConfigParser parser = ConfigParser() parser.read('setup.cfg') if parser.has_section('egg_info') and 'tag_build' in parser.options('egg_info'): version = parser.options('egg_info')['tag_build'] else: version = calculate_version() dist.metadata.version = version And register this as a 'distutils.setup_keywords' entry point in your plugin project. You then need only include a 'use_hg_version = True' in your setup() call, along with a setup_requires to ensure the plugin is available. Now, there is one minor hitch with this; as shown above, this code will double-up version strings in certain circumstances; specifically, if an 'egg_info' is done from an sdist -- which is going to happen if you build pretty much anything from an sdist, be it an sdist, egg, RPM, or anything else. There isn't any easy way to work around this at the moment (although I will implement a formal fix in later releases of setuptools). In the meantime, you can monkeypatch thus, in the same plugin where you implement the above function: from setuptools.command.egg_info import egg_info old_tagged_version = egg_info.tagged_version def tagged_version(self): if self.distribution.use_hg_version: return safe_version(self.distribution.get_version()) else: return old_tagged_version(self) egg_info.tagged_version = tagged_version Whew. This was a tough one to figure out, and it's a little hacky. Probably in 0.7 I'll just factor this into a separate entry point group for version calculations, so that it's not as much trouble to do something like this.

2 1

Announcing buildout_versions 1.0
by Chris Withers 03 Aug '10

03 Aug '10

Hi All, I'm pleased to announce the first release of buildout_versions. This is my take on buildout.dumppickedversions in that it's purpose is to make the user of a buildout aware if any package versions have been picked by buildout rather than specified by the buildout configuration. It has two important differences: - if no versions need to be picked, it generates no output - if you specify recording of picked versions to a file, that file is only ever appended to, not overwritten. The PyPI page is here: http://pypi.python.org/pypi/buildout_versions The documentation is here: http://packages.python.org/buildout_versions This extensions is also fully tested. If you have any problems or suggestions, please let me know on this list! cheers, Chris

2 3

buildout 2
by Jim Fulton 02 Aug '10

02 Aug '10

FYI. After 1.5 lands and the dust settles, I intend to look at refactoring buildout pretty significantly, primarily to make maintenance simpler. Jim -- Jim Fulton

3 2

easy_install install file permissions
by Eric Schug 01 Aug '10

01 Aug '10

Hello, I was having problem getting installed egg files to work until I realized that they had the wrong permissions set. It seems that on my machine easy_install is installing files with permissions set to -rw-r-----. How do I change this so that my files are installed with og+r, automatically so that I don't have to go back and fix them? Thanks Eric Schug Email: schugschug(a)gmail.com http://trilogysci.webfactional.com

2 1

Re: [Distutils] How to customize egg_info behavior
by P.J. Eby 01 Aug '10

01 Aug '10

At 12:39 PM 7/31/2010 -0700, Jason R. Coombs wrote: >I'm using setuptools 0.6c11. > >I'd like to programmatically customize the way the egg_info command >is run. That is, in my setup.py, I would like to run some functions >to determine the tag-build, tag-date, and tag-svn-revision >parameters to egg_info. Are there parameters > >How is this task best accomplished? Do I subclass the egg_info >Command? If so, do I just specify >cmdclass={'egg_info':my_custom_egg_info} ? Or would you recommend >another approach? You can just do this in your setup script: setup( ... options = dict(egg_info = dict(tag_build = "whatever", ...)), ... ) Replacing "whatever", of course, with your programmatic calculation.

2 1