Mailman 3 October 2011 - Distutils-SIG

easy_install execution question
by Chris Jerdonek 28 Oct '11

28 Oct '11

Hi, I have one more question for the time being. This regards how the easy_install script works. I use Mac OSX, and my /usr/bin directory contains three versions of the easy_install script: easy_install, easy_install-2.5, and easy_install-2.6. Based on some debugging lines I tried inserting, when I execute the script called simply "easy_install", the script seems to execute just the first line (namely "#!/usr/bin/python"), and then seems to immediately jump to executing easy_install-2.6. I was curious about the mechanism that allows the Python interpreter to jump mysteriously from one file to another. This doesn't seem to be evident from the easy_install scripts themselves. What causes this behavior? Thanks, --Chris

3 3

an approach for inspectable setup scripts
by Jason R. Coombs 27 Oct '11

27 Oct '11

In http://lists.idyll.org/pipermail/testing-in-python/2011-October/004447.html, Barry Warsaw kicked off a discussion on testing various packages within the Python Package Index (pypi). As part of this discussion, I mentioned a technique I've been using internally for a while to write setup scripts (old distutils/setuptools style) such that they're more robust and introspectable. Instead of writing the following in my scripts: from setuptools import setup setup( name = 'foo', install_requires = 'bar', ) I write the following: setup_params = dict( name = 'foo', install_requires = 'bar', ) if __name__ == '__main__': from setuptools import setup setup(**setup_params) While slightly more verbose, this technique has a couple of benefits. First, it means that code traversal algorithms (such as test discovery) don't inadvertently execute the setup script. Second, it allows the script to be read via import or execfile without necessarily invoking the setup() function. This allows a third-party product, such as the Cheese Taster to open up a project and easily inspect its setup parameters. Also, you'll note the setuptools requirement is deferred until the script is run, and isn't necessary to construct the parameters. Furthermore, if there is other side-effect behavior, it can be invoked from inside the __main__ block. I share this with the community for your feedback. Is there any reason this technique shouldn't be adopted in general? Also, how can a third-party product detect whether a setup script is safe in this way? I don't think it would be possible in general, but perhaps packagers could include a directive near the head to indicate such. Consider: # -*- script-disposition: import-safe -*- Or similar. Alternatively, a tool could be built to compile and statically analyze the code to detect the presence of setup_params, though would be more likely to encounter false positives. What downsides am I missing? How could this technique be improved? Would it be difficult to take these parameters and generate package metadata (DistributionMetadata) from it? I look forward to any feedback you have. Regards, Jason R. Coombs

2 1

Problem pip installing sqlalchemy-migrate with latest distribute
by Mark McLoughlin 25 Oct '11

25 Oct '11

Hey, I've just reported this sqlalchemy-migrate issue: http://code.google.com/p/sqlalchemy-migrate/issues/detail?id=131 I thought it was worth pointing out here in case anyone thinks it's not an sqlalchemy-migrate specific issue. Cheers, Mark.

2 1

Re: [Distutils] [buildout-versions] Can buildout-versions made to work for zc.buildout v1.4.*? (#1)
by Chris Withers 25 Oct '11

25 Oct '11

Hi Wouter, On 20/10/2011 18:58, Wouter Vanden Hove wrote: > I have not delved deep in to buildout-extensions, but why can buildout.dumppickedversions be used with zc.buildout v1.4.* > while buildout-versions requires 1.5.0? buildout-versions has a bit more functionality that buildout.dumppickedversions now ;-) > is it doable to add compatibility for zc.buildout v1.4.*? What's stopping you moving to buildout 1.5? Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

2 2

distutils/cygwincompiler.py not compatible with new releases of MingW
by Seppo Yli-Olli 25 Oct '11

25 Oct '11

Hi, newer versions of MingW no longer have -mno-cygwin parameter for their GCC (4.6.1 here) et al which means that compiling with that out of the box fails. Is there some kind of bug tracker for distutils where this could be followed (I'd be willing to study more in-depth when this broke)? Assumably -mno-cygwin needs to be conditional on the compiler version for compiler command and linker version for linker commands so this fixing this will not break compatibility. Simply removing all instances of -mno-cygwin from self.set_executables in Mingw32Compiler's __init__ fixed it which means it should not be essentially difficult to overcome as long as right conditions on when -mno-cygwin must be used are determined. - Seppo Yli-Olli

2 1

virtualenv error
by Andrea Crotti 25 Oct '11

25 Oct '11

I just simply try to run "virtualenv -p python2.7 app" and I get this error: Renaming /usr/lib/python2.7/site-packages/setuptools_git-0.4.2-py2.7.egg-info into /usr/lib/python2.7/site-packages/setuptools_git-0.4.2-py2.7.egg-info.OLD.1319554103.83 error: Permission denied But why does it try to change something system-wide if I just run it as a normal user? I have never seen this kind of error before, any hint?

1 1

Correct way to include (debian) program icons.
by Mac Ryan 25 Oct '11

25 Oct '11

Hello, I was wondering if there is a way in distutils to include/indicate a program icon that will be used in the program menus / desktop shortcuts. I'm actualy packaging for debian with `stdeb` and I was expecting some stdeb-specific way to include the icon in the pacakge but to the best of my knowledge there isn't. I'm presently including in my setup.py file: data_files=[('/usr/share/pixmaps/', ['my-package-name.xpm'])], but this - while working - seems the wrong thing to do, as it insert in the general python package something that is platform-specific. Any ideas or primers on the subject? Thanks in advance, /mac

6 8

Re: [Distutils] [buildout-versions] Can buildout-versions made to work for zc.buildout v1.4.*? (#1)
by Chris Withers 24 Oct '11

24 Oct '11

On 21/10/2011 23:35, Jonathan Ballet wrote: > I never used buildout-versions, but buildout.dumppickedversions is quite > buggy IMO. Yeah, it's one of the reasons why I forked it... > I worked a bit to make the output more stable over successive run: my > use case was to bootstrap a project and keep using the same dependencies > and versions (no matter what they were in the beginning) as long as i > didn't change the versions.cfg file. Yeah, that's how buildout-versions works, I'd encourage you to give it a try and let me know if you hit any problems... > But there are many other corner cases that aren't detected by the > extension, and the tests are so long to run and so dependant on > setuptools or distribute that I stopped working on it and stopped using > it also. If I would need such functionality again, I will head towards > buildout-versions instead... buzzkill:buildout-versions chris$ bin/test -v Running tests at level 1 Running zope.testrunner.layer.UnitTests tests: Set up zope.testrunner.layer.UnitTests in 0.000 seconds. Running: ............................................... Ran 47 tests with 0 failures and 0 errors in 17.296 seconds. Tearing down left over layers: Tear down zope.testrunner.layer.UnitTests in 0.000 seconds. There is one slow test in there, but I don't think that's outrageously slow... cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

1 0

Re: [Distutils] [buildout-versions] Can buildout-versions made to work for zc.buildout v1.4.*? (#1)
by Chris Withers 24 Oct '11

24 Oct '11

On 21/10/2011 19:29, Wouter Vanden Hove wrote: > 1) Plone is officially still using zc.buildout 1.4.* > see for example http://dist.plone.org/release/4.1.2/versions.cfg refers to > http://download.zope.org/Zope2/index/2.13.10/versions.cfg which refers to > http://download.zope.org/zopetoolkit/index/1.0.4/ztk-versions.cfg > --> zc.buildout = 1.4.4 Yeah, but you'll be fine to specify a newer version of buildout, eg: [buildout] extends = http://dist.plone.org/release/4.1.2/versions.cfg version = versions [versions] zc.buildout = 1.5.whatever > 2) unrelated to that, I'd like to have my buildout-directories as a virtualenv > but virtualenv conflicts with zc.buildout>=1.5 > see http://mail.python.org/pipermail/distutils-sig/2010-April/016062.html Well, this is kind of irrelevant, buildout 1.5 makes wrapping the buildout in a virtualenv unnecessary... cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

1 0

Search option and easy_install
by blueeagle2＠gmail.com 23 Oct '11

23 Oct '11

I was wondering if easy_install has a search option so I can find the packages I need to install.

2 1