Mailman 3 May 2009 - Distutils-SIG

[issue74] pkg_resources.ImpWrapper documented but no longer exists
by Nicholas Riley May 31, 2009

May 31, 2009

New submission from Nicholas Riley <com-pythonbugs(a)sabi.net>: pkg_resources.ImpWrapper was (and is) mentioned in the documentation (pkg_resources.txt), and as a result has been used by modules such as modulegraph (http://svn.pythonmac.org/modulegraph/modulegraph/trunk/modulegraph/modulegr… ). However, recent versions of pkg_resources remove this definition. Given this class appears in the documentation and still exists, just not with that name, it would be useful if backwards compatibility could be retained. ---------- messages: 296 nosy: nriley priority: bug status: unread title: pkg_resources.ImpWrapper documented but no longer exists _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue74> _______________________________________________

1 0

Patch for clean command
by James May 29, 2009

May 29, 2009

Hi, I'm certaintly new to distutils and setuptools, however I figured I'd send in this patch, and either it will get merged because it's a great idea or someone will perhaps tell me why this doesn't exist already. (or maybe it does and i can't find it) In any case, it adds the pyc option to the clean command so that the .pyc can be removed on request. Personally i'll have a [clean] pyc=1 option in my setup.cfg, but that's for my convenience. cheers, _J [attached: patch and modified file]

2 2

eggs and Python Unicode variants (UCS2, UCS4)
by Martijn Faassen May 29, 2009

May 29, 2009

Hi there, In the lxml project (http://codespeak.net/lxml), we've just noticed the following problem with lxml eggs: you can easy_install an egg that won't work for your Python. This is because Python can be compiled with either 2 or 4 bytes unicode as its internal representation. Any egg that contains compiled C code that uses unicode such as lxml will run into trouble: if it's compiled with a 4 bytes unicode Python, it won't work on a 2 bytes unicode Python, and vice versa. This problem is fairly common in Linux. Many distributions such as Ubuntu and Fedora compile their python with 4 bytes unicode internal representation. If you compile a Python interpreter by hand it defaults to 2 bytes unicode, however. Hand-building a Python interpreter is done fairly commonly by Linux sysadmins for various reasons. It would therefore be very nice if it became possible to make eggs for the different unicode compilation options of Python. This configuration dimension is a real world issue for any binary Python module that does anything with unicode text.. In an earlier mail to this list: http://mail.python.org/pipermail/distutils-sig/2005-October/005222.html M.-A. Lemburg and Phillip Eby had the following discussion: [MAL] >>Please make sure that your eggs catch all possible >>Python binary build dimensions: >> >>* Python version >>* Python Unicode variant (UCS2, UCS4) >>* OS name >>* OS version >>* Platform architecture (e.g. 32-bit vs. 64-bit) [PJE] >As far as I know, all of this except the Unicode variant is captured in >distutils' get_platform(). And if it's not, it should be, since it >affects any other kind of bdist mechanism. I'm not sure whether this means this needs to be escalated from setuptools to the Python interpreter level itself. With this mail, I've done the job escalating this lxml problem to what appears to be the right place, though. :) Thanks, Martijn

5 5

Buildout: caching of base configuration ('extends')
by Thomas Lotze May 28, 2009

May 28, 2009

Hi, I've been implementing a download API for buildout and have reached the point where I'd like to try using it for downloading the base config files referenced from a buildout config by the 'extends' option. This would have the benefit of allowing to cache those config files and being able to run a buildout using that feature while being offline. However, I'd like to discuss two points about doing this: - I think buildout should not unconditionally use a cached copy of a base configuration file. While it is sensible in other use cases to never access the network if a file is found in the cache, base configs can be expected to change and should IMHO be taken from the cache only when offline mode is active or an attempt at downloading failed. - The download cache to be used is configured as one of the options that are read from either ~/.buildout/default.cfg or buildout.cfg and their respective bases. In order to keep things simple, I'd suggest to use a download cache only if specified directly inside any of these two files, and ignore download-cache options in any downloaded base configs. This would be an exception to how options read from config files are combined, but one I deem worthwhile. I'd allow for configuring and using different download caches in those two files, though. That way, bases of the user's default config can be cached centrally while allowing to keep project-related stuff in a different place. Opinions? -- Thomas

3 7

[Buildout] Include-dirs
by Svenn Helge Grindhaug May 28, 2009

May 28, 2009

Hi, I'm trying to do something similar to the custom egg building in the tutorial, http://www.buildout.org/docs/tutorial.html?highlight=location#custom-egg- building I have the following files: setup.py ********* from setuptools import setup, find_packages setup( name='myproject', version='3.3.0', packages=find_packages('src'), package_dir = {'': 'src'}, include_package_data = True, install_requires=['setuptools', 'numpy', 'ScientificPython'], zip_safe = False, ) buildout.cfg ************* [buildout] parts = numpy ScientificPython mypy [numpy] recipe = zc.recipe.egg find-links = http://sunet.dl.sourceforge.net/sourceforge/numpy/numpy-1.3.0.tar.gz eggs= numpy [ScientificPython] recipe = zc.recipe.egg:custom egg=ScientificPython find-links = http://sourcesup.cru.fr/frs/download.php/2372/ScientificPython-2.9.0.tar.gz include-dirs = ${numpy:location}/numpy/core/include [mypy] recipe = zc.recipe.egg:script eggs = numpy ScientificPython interpreter = python ------------ The ScientificPython package need some header files located in the numpy package/egg. I get an error when using ${numpy:location} Error: Referenced option does not exist: numpy location When I use the absolute path to the include dir it works. What am I doing wrong? Best regards, Svenn.

1 0

Re: [Distutils] PEP 376 up-to-date
by P.J. Eby May 27, 2009

May 27, 2009

At 11:01 AM 5/26/2009 +0200, Tarek Ziadé wrote: >Just one point though: > >- do we want to scan egg-info directories that are *directly* added in >sys.path ? No. Such a directory does not represent an importable egg on sys.path. If you mean an .egg file or directory that's directly on sys.path, then that's a bit different. Are you planning to support those? In that event you would need another EggInfo subclass anyway, and you could have the directory (or "PathEntry", perhaps?) constructor simply wrap a single such EggInfo in that event. Or, you can handle it the way pkg_resources does, which is to convert target paths into PEP 302 importer objects, and then use the importer's type to determine what sort of handler should be used for it.

2 1

[issue72] easy_install violates SELinux policies
by Jonathan Cervidae May 26, 2009

May 26, 2009

New submission from Jonathan Cervidae <jonathan.cervidae(a)gmail.com>: I get AVC's aftef installing egg's with easy_install. The AVS are that the files are mislabeled as: unconfined_u:object_r:user_tmp_t:s0 When I we want them to be: system_u:object_r:lib_t:s0 It stops python from accessing the files. I haven't looked at the source code, but those contexts suggest that easy_install is downloading the egg file to a temp directory then moving (not copying) it from the temp dir to /usr/lib/python<VERSION>/site-packages. This is clearly a good thing as unnecessary copying should be avoid and it's easy to fix too. I notice there is a python module called selinux installed on my system. So you need to try and import that. If you succeed you can try and restore the context after moving it to the new location and just ignore any error on that too. ---------- files: fix.txt messages: 292 nosy: jcervidae priority: bug status: unread title: easy_install violates SELinux policies Added file: http://bugs.python.org/setuptools/file53/fix.txt _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue72> _______________________________________________

1 0

Re: [Distutils] Side by side debug/non-debug eggs
by P.J. Eby May 22, 2009

May 22, 2009

At 12:00 PM 5/22/2009 -0400, Jean-Paul Calderone wrote: >On Fri, 22 May 2009 11:33:54 -0400, "P.J. Eby" <pje(a)telecommunity.com> wrote: >>At 09:45 AM 5/22/2009 -0400, Jean-Paul Calderone wrote: >>>Hello all, >>> >>>Prior to eggs, if I wanted to have debug and non-debug versions of an >>>extension module available, I could build and install the extension >>>twice and the modules would happily co-exist, for example: >>> >>> >>> $ python setup.py build install >>> ... >>> $ python-dbg setup.py build install >>> ... >>> $ .../site-packages/twisted/python$ ls *.so >>> _epoll_d.so _epoll.so >>> $ .../site-packages/twisted/python$ >>>If I then ran a debug build of Python, the debug extension would be loaded. >>>When I ran a normal build of Python, the non-debug extension would >>>be loaded. >>>However, with eggs, each new egg completely replaces the last egg. There >>>seems to be no possibility for side-by-side builds. Am I overlooking a >>>feature of eggs or of setuptools? >> >>Have you tried "setup.py develop"? This builds extensions in-place >>in the source tree and adds the source tree to sys.path. > >Aware of it, but I haven't tried it. In this use, it sounds very >similar to "setup.py build_ext -i", which also partially solves the >problem. Unfortunately, some packages have their source laid out >such that they cannot actually be used in-place, only after they've >been installed. The only other thing I can think of is installing in backward-compatibility mode, i.e. "setup.py install --single-version-externally-managed" (with a filename given to --record).

1 0

Re: [Distutils] [Trac] Re: Help packaging plugin : Source distribution
by P.J. Eby May 22, 2009

May 22, 2009

At 12:43 PM 5/22/2009 -0500, Olemis Lang wrote: >On Thu, May 21, 2009 at 3:56 PM, P.J. Eby <pje(a)telecommunity.com> wrote: > > At 11:15 AM 5/20/2009 -0500, Olemis Lang wrote: > >> > >> On Wed, May 20, 2009 at 10:09 AM, Jeff Hammel <jhammel(a)openplans.org> > >> wrote: > >> > > >> > You have to verbosely include them with package data. IMHO, this is a > >> > setuptools bug. E.g.: > >> > > >> > package_data={ 'geotrac': ['templates/*', 'htdocs/*'] }, > >> > include_package_data=True, > >> > > >> > This is probably not quite right :(, but you get the idea. > >> > >> I just tried this and doesnt include files for sdist ... :( > >> > >> Looking forward for further hints : maybe it's just something I'm > >> doing wrong, dont know, but eggs are ok so I'm not sure > > > > If you are not using a revision control system plugin, you will > have to list > > sdist files in MANIFEST.in; > >Thanks, I included files in MANIFEST.in now I can distribute source >packages for TracGViz [1]_ & TracPyTppTheme [2]_ so that EGGs can be >built for different Py versions or whatever ... > >So this is the way ! > >PS: BTW , I dont get the idea about specifying things twice (I mean >package_data & MANIFEST.in ;) Is there a «logical» reason for this ? I >mean why sdist doesnt look for the data specified in package_data ? Or >alternately, what is the reason for having MANIFEST.in too ? That's what distutils does. setuptools improves on it by adding revision control support. But if you don't use a revision control plugin or some other sort of file finder, you have to do it the old distutils way.

1 0

Re: [Distutils] Side by side debug/non-debug eggs
by P.J. Eby May 22, 2009

May 22, 2009

At 09:45 AM 5/22/2009 -0400, Jean-Paul Calderone wrote: >Hello all, > >Prior to eggs, if I wanted to have debug and non-debug versions of an >extension module available, I could build and install the extension >twice and the modules would happily co-exist, for example: > > > $ python setup.py build install > ... > $ python-dbg setup.py build install > ... > $ .../site-packages/twisted/python$ ls *.so > _epoll_d.so _epoll.so > $ .../site-packages/twisted/python$ >If I then ran a debug build of Python, the debug extension would be loaded. >When I ran a normal build of Python, the non-debug extension would be loaded. >However, with eggs, each new egg completely replaces the last egg. There >seems to be no possibility for side-by-side builds. Am I overlooking a >feature of eggs or of setuptools? Have you tried "setup.py develop"? This builds extensions in-place in the source tree and adds the source tree to sys.path.

3 3

how to set cc correctly?
by rupert.thurner May 22, 2009

May 22, 2009

how could one set the compiler correctly? http://opencsw has a setuptools package, which does not use the cc in the path, but in /opt/studio/SOS11/SUNWspro/bin/cc so the following happens: # CC=/opt/SUNWspro/bin/cc easy_install genshi Searching for genshi Reading http://pypi.python.org/simple/genshi/ Reading http://genshi.edgewall.org/ Reading http://genshi.edgewall.org/wiki/Download Best match: Genshi 0.5.1 Downloading http://ftp.edgewall.com/pub/genshi/Genshi-0.5.1.zip Processing Genshi-0.5.1.zip Running Genshi-0.5.1/setup.py -q bdist_egg --dist-dir /tmp/ easy_install-7yiT65/Genshi-0.5.1/egg-dist-tmp-Cp42JQ warning: no previously-included files found matching 'doc/ 2000ft.graffle' warning: no previously-included files matching '*' found under directory 'doc/logo.lineform' unable to execute /opt/studio/SOS11/SUNWspro/bin/cc: No such file or directory ********************************************************************** WARNING: An optional C extension could not be compiled, speedups will not be available. ********************************************************************** Adding Genshi 0.5.1 to easy-install.pth file Installed /opt/csw/lib/python2.6/site-packages/Genshi-0.5.1-py2.6- solaris-2.10-sun4v.egg Processing dependencies for genshi Finished processing dependencies for genshi

3 15

Side by side debug/non-debug eggs
by Jean-Paul Calderone May 22, 2009

May 22, 2009

Hello all, Prior to eggs, if I wanted to have debug and non-debug versions of an extension module available, I could build and install the extension twice and the modules would happily co-exist, for example: $ python setup.py build install ... $ python-dbg setup.py build install ... $ .../site-packages/twisted/python$ ls *.so _epoll_d.so _epoll.so $ .../site-packages/twisted/python$ If I then ran a debug build of Python, the debug extension would be loaded. When I ran a normal build of Python, the non-debug extension would be loaded. However, with eggs, each new egg completely replaces the last egg. There seems to be no possibility for side-by-side builds. Am I overlooking a feature of eggs or of setuptools? Thanks, Jean-Paul

1 0

Re: [Distutils] easy_install picks windows egg on Linux
by P.J. Eby May 21, 2009

May 21, 2009

At 01:49 PM 5/21/2009 -0400, Jean-Paul Calderone wrote: >Downloading >http://pypi.python.org/packages/2.5/p/pyOpenSSL/pyOpenSSL-0.9.py2.5-winxp32… What's bizarre is that that's not a valid egg filename; they must have renamed it at some point. The filename is invalid in two ways: first, it has a '.' between the version and the Python version (it should be a '-') and second, 'winxp32' is not a valid platform name. I would suggest contacting the PyOpenSSL maintainers to find out why they have renamed it in this fashion; .egg files should never be renamed under any circumstances. (I'm actually surprised that easy_install is recognizing it at all, but basically it appears to be treating it as if it's a non-platform-specific egg. That's arguably a bug.) >zipimport.ZipImportError: not a Zip file This part is an expected failure with a --dry-run. It perhaps could be fixed, but the problem is that with --dry-run on, the egg is not moved to the target directory, so when it tries to create a Distribution object for the installed egg, it fails. This has nothing to do with the version problem - you will probably see this occur at the end of any --dry-run install, unless an identically-named egg was was already present.

2 1

[issue71] type of renamed eggs misdetected by easy_install
by Jean-Paul Calderone May 21, 2009

May 21, 2009

New submission from Jean-Paul Calderone <exarkun(a)twistedmatrix.com>: Due to user error, an egg which should have been a Python 2.5 Windows binary egg got renamed to "pyOpenSSL-0.9.py2.5-winxp32.egg" and uploaded to PyPI. easy_install will select this egg for installation on Linux, though it is not usable on that platform. ---------- messages: 290 nosy: exarkun priority: bug status: unread title: type of renamed eggs misdetected by easy_install _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue71> _______________________________________________

1 0

easy_install picks windows egg on Linux
by Jean-Paul Calderone May 21, 2009

May 21, 2009

Hi all, I just noticed that easy_install selects a Windows binary egg when trying to install pyOpenSSL on Linux. Predictably, this fails: $ PYTHONPATH=/tmp/junk6 easy_install --install-dir /tmp/junk6 --dry-run pyOpenSSL Creating /tmp/junk6/site.py Searching for pyOpenSSL Reading http://pypi.python.org/simple/pyOpenSSL/ Reading http://pyopenssl.sourceforge.net/ Reading http://launchpad.net/pyopenssl Best match: pyOpenSSL 0.9.py2.5 Downloading http://pypi.python.org/packages/2.5/p/pyOpenSSL/pyOpenSSL-0.9.py2.5-winxp32… Processing pyOpenSSL-0.9.py2.5-winxp32.egg Moving pyOpenSSL-0.9.py2.5-winxp32.egg to /tmp/junk6 Traceback (most recent call last): File "/usr/bin/easy_install", line 8, in <module> load_entry_point('setuptools==0.6c8', 'console_scripts', 'easy_install')() File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 1671, in main with_ei_usage(lambda: File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 1659, in with_ei_usage return f() File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 1675, in <lambda> distclass=DistributionWithoutHelpCommands, **kw File "/usr/lib/python2.5/distutils/core.py", line 151, in setup dist.run_commands() File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands self.run_command(cmd) File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 211, in run self.easy_install(spec, not self.no_deps) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 446, in easy_install return self.install_item(spec, dist.location, tmpdir, deps) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 476, in install_item dists = self.install_eggs(spec, download, tmpdir) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 619, in install_eggs return [self.install_egg(dist_filename, tmpdir)] File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 696, in install_egg return self.egg_distribution(destination) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 661, in egg_distribution metadata = EggMetadata(zipimport.zipimporter(egg_path)) zipimport.ZipImportError: not a Zip file exarkun@charm:/tmp$ Is this a known issue? Jean-Paul

1 0

[issue70] Patch to remove call to /usr/bin/sw_vers on OSX
by Ronald Oussoren May 21, 2009

May 21, 2009

New submission from Ronald Oussoren <ronaldoussoren(a)mac.com>: The attached patch for setuptools 0.6c9 replaces a shell callout to /usr/bin/sw_vers to using platform.mac_ver on OSX. The primary reason for writing the patch is that gdb tends to cause havoc with calls to os.popen (the debugged process gets an signal and debugging gets aborted). This patch makes it a lot more convenient to run "setup.py test" in a gdb session, without this patch I regularly have to re-run the tests several times until the callout to sw_vers succeeds. ---------- files: setuptools-no-sw_vers.patch messages: 289 nosy: ronaldoussoren priority: feature status: unread title: Patch to remove call to /usr/bin/sw_vers on OSX Added file: http://bugs.python.org/setuptools/file52/setuptools-no-sw_vers.patch _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue70> _______________________________________________

1 0

PEP 376 APIs
by Tarek Ziadé May 21, 2009

May 21, 2009

Hello As discussed in python-dev, I have started a prototype for pep 376 to define the APIs. I have changed the APIs with Phillip feedback (eg using holders) It's located here : http://bitbucket.org/tarek/pep376 The idea would be to refine it until everyone finds it good, then update PEP 376 accordingly, then move forward with it It's on bitbucket, so feel free to create a branch to demonstrate a change. Regards Tarek -- Tarek Ziadé | http://ziade.org

1 0

Specifying version information once
by Jean-Paul Calderone May 21, 2009

May 21, 2009

Hello, For a long time, the idiom I've used to specify version information in my distutils-based packages has been this simple one: put version information into the Python package somewhere, structure the source layout so that the package can be imported directly from an unpacked source tarball (or vcs wc), and import the version into setup.py. This worked great. And I only had to define my version once. Increasingly, it seems that new distutils-related tools don't support this idiom and break in various ways. (eg http://divmod.org/trac/ticket/2629 http://divmod.org/trac/ticket/2831 ) What is the recommendation for specifying version information in a way which is compatible with all these new tools? Jean-Paul

7 11

buildout/setuptools setup_requires and test_requires
by Chris Withers May 20, 2009

May 20, 2009

Wichert Akkerman wrote: > Previously Chris Withers wrote: >> Wichert Akkerman wrote: >>>> BUT, one thing I have noticed so far is that after running buildout, I >>>> end up with eggs for Paste, PasteDeploy and PasteScript in >>>> pylons_buildout/myproject, which is wrong. >>> Everything in setup_requires and test_requires is installed there, >> Why? >> >>> and >>> buildout can't prevent that. >> Again, why? > > setuptools internals do that, and buildout has no influence over that as > far as I know. If you want to discuss that distutils-sig is the right > list. Sorry, still not sure I follow you... Are you saying that any packages specified in setup_requires and test_requires will be installed in the path of the package that specified them rather than the same location as all other eggs? If so, that would seem to be a bug, no? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

2 2

Re: [Distutils] Specifying version information once
by P.J. Eby May 20, 2009

May 20, 2009

At 09:05 PM 5/19/2009 -0400, Jean-Paul Calderone wrote: >On Tue, 19 May 2009 20:49:37 -0400, "P.J. Eby" <pje(a)telecommunity.com> wrote: >>At 04:28 PM 5/19/2009 -0400, Jean-Paul Calderone wrote: >>>On Tue, 19 May 2009 16:23:16 -0400, "P.J. Eby" >>><pje(a)telecommunity.com> wrote: >>>>At 02:21 PM 5/19/2009 -0400, Jean-Paul Calderone wrote: >>>>>What is the recommendation for specifying version information in >>>>>a way which >>>>>is compatible with all these new tools? >>>> >>>>Don't import the file with your version info; execfile() it instead. >>>> >>>>That is, you can have a somepackage.version module for importing, >>>>but from within your setup.py, do >>>>execfile('somepackage/version.py') instead, so as to avoid >>>>actually importing your package (and anything it depends on). >>> >>>execfile() doesn't set __name__ properly; setting __name__ in a namespace >>>passed to execfile() produces a CPython SystemError. At the moment my >>>version code depends on __name__ being set. I'm sure I could work around >>>this, but it'd be better if I didn't have to worry about code in the >>>version module being executed in two unrelated contexts. Any other >>>suggestions? >> >>Well, if you're okay with depending on setuptools, you could have >>your version code do this: >> >> version = pkg_resources.require('ThisProject')[0].version >> >>And *only* define the version in setup.py, but don't import or run that code. > >I don't think I'm ready to make setuptools a mandatory dependency yet. > >>Of, if you can't depend on setuptools (no pun intended), the only >>other thing I can think of would be to put the version in a text >>file by itself, and have both the version code and setup.py read that file. > >That's an idea that's come up before. I'm curious to here if anyone has >tried it and what their experiences have been. Oh, now that I think of it, there is one other thing that I've done. For some of my packages (including setuptools itself), I use a script that automatically searches and replaces version numbers, and stores the current version number in a configuration file. Another configuration file specifies what files to edit and what format to insert the numbers in. So, I just do a quick command line like './version incr build' to increment the most-minor version number in the docs, the setup.py, and even to edit my release script. And I suppose one last idea that you could use would be to define your version string in the module in such a way that setup.py could read it with a regular expression match, so it wouldn't be actually executing the code.

1 0

Re: [Distutils] Specifying version information once
by P.J. Eby May 20, 2009

May 20, 2009

At 04:28 PM 5/19/2009 -0400, Jean-Paul Calderone wrote: >On Tue, 19 May 2009 16:23:16 -0400, "P.J. Eby" <pje(a)telecommunity.com> wrote: >>At 02:21 PM 5/19/2009 -0400, Jean-Paul Calderone wrote: >>>What is the recommendation for specifying version information in a way which >>>is compatible with all these new tools? >> >>Don't import the file with your version info; execfile() it instead. >> >>That is, you can have a somepackage.version module for importing, >>but from within your setup.py, do >>execfile('somepackage/version.py') instead, so as to avoid actually >>importing your package (and anything it depends on). > >execfile() doesn't set __name__ properly; setting __name__ in a namespace >passed to execfile() produces a CPython SystemError. At the moment my >version code depends on __name__ being set. I'm sure I could work around >this, but it'd be better if I didn't have to worry about code in the >version module being executed in two unrelated contexts. Any other >suggestions? Well, if you're okay with depending on setuptools, you could have your version code do this: version = pkg_resources.require('ThisProject')[0].version And *only* define the version in setup.py, but don't import or run that code. Of, if you can't depend on setuptools (no pun intended), the only other thing I can think of would be to put the version in a text file by itself, and have both the version code and setup.py read that file.

2 1

Re: [Distutils] Specifying version information once
by P.J. Eby May 19, 2009

May 19, 2009

At 02:21 PM 5/19/2009 -0400, Jean-Paul Calderone wrote: >Hello, > >For a long time, the idiom I've used to specify version information in my >distutils-based packages has been this simple one: put version information >into the Python package somewhere, structure the source layout so that the >package can be imported directly from an unpacked source tarball (or vcs wc), >and import the version into setup.py. This worked great. And I only had to >define my version once. > >Increasingly, it seems that new distutils-related tools don't support this >idiom and break in various ways. (eg > > http://divmod.org/trac/ticket/2629 > http://divmod.org/trac/ticket/2831 >) > >What is the recommendation for specifying version information in a way which >is compatible with all these new tools? Don't import the file with your version info; execfile() it instead. That is, you can have a somepackage.version module for importing, but from within your setup.py, do execfile('somepackage/version.py') instead, so as to avoid actually importing your package (and anything it depends on).

2 1

Changes in r72585
by Tim Golden May 19, 2009

May 19, 2009

[coming from a thread on python-win32: http://mail.python.org/pipermail/python-win32/2009-May/009130.html ] In short: changes to build_ext.py in r72585 caused the pywin32 packages to stop building correctly. The changes in question are those which call get_ext_filename with the short form of the ext.name (without the package prefix). The pywin32 setup.py expects the fully-qualified name in the get_ext_filename in its subclass. Now I don't know whether this is an incautious change to build_ext or a false -- altho' historically valid -- assumption on the part of the pywin32 developers. You can see their code here at line 1119: http://pywin32.cvs.sourceforge.net/viewvc/pywin32/pywin32/setup.py?revision… I'm afraid I'm fairly ignorant of the design rationale behind distutils; I'm hoping someone here has a better idea :) Opinions? TJG

3 11

Re: [Distutils] PEP 376 - critique - why more sub-directories within python aren't needed...
by P.J. Eby May 19, 2009

May 19, 2009

At 12:59 PM 5/19/2009 +1200, Noah Gift wrote: >On Tue, May 19, 2009 at 12:59 PM, P.J. Eby ><<mailto:pje@telecommunity.com>pje(a)telecommunity.com> wrote: >At 08:34 PM 5/18/2009 -0400, David Lyon wrote: >Why not keep the .EGG_INFO files in the site-packages directory? > > >That's where they go. Each installed project has its own .egg-info >subdirectory containing the listed files. See the EggFormats >documentation for details. PEP 376 is just adding stdlib support >for the .egg-info format defined by setuptools, and adding a new >RECORD file to it. > > >But if this implementation is the same as eggs, then each egg >directory is then scanned and imported into sys.path, unlike normal >packages which are called via simple namespaces. You are confused. Please refer to the EggFormats documentation for the layout difference between .egg and .egg-info: http://peak.telecommunity.com/DevCenter/EggFormats .egg-info eggs look just like "normal" distutils installs, except for the addition of a "project-version-pyversion.egg-info" subdirectory alongside the code. In Python 2.5 and up, distutils also installs packages this way, except the "project-version-pyversion.egg-info" is a file instead of a directory - as documented in the above documentation. PEP 376 is simply proposing stdlib support for querying the existing formats, and adding a new standard RECORD file to go in that directory.

1 0

Re: [Distutils] PEP 376 - site-directories and site.addsitedir
by Tarek Ziadé May 19, 2009

May 19, 2009

On Thu, May 14, 2009 at 12:33 PM, Noah Gift <noah.gift(a)gmail.com> wrote: > One thing that isn't clear to me is whether this could then lead to a > potentially new third party packaging system, or library, that will just do > the same thing again, and create a linear scanning algorithm. Is there a > way to architect things in a way that will never increase the number of > stats to the filesystem or limit them? I'd like to make a difference between what is "importable" and what is "installed" in Python. what's "installed" for me is what is in a site-packages directory that contains egg-info directories. At startup, you have to visit at least once every site-packages directory, that's linear and that won't go away. But it's OK eventually, with a cache or a memory index that takes care of making the lookup code non-linear after Python has started *as long as sys.path is not involved* So, by restricting this API to site-packages (e.g. "installed"), rather than sys.path (eg "importable"), is just a way of limiting the scope to some specific places where you are supposed to install packages (and where egg-info files are located). When a program is launched, the site-packages places should be limited to: - the python site-packages (wether is central, wether it's local, using virtualenv) - the per user site-packages (PEP 370) - maybe a third place added manually using site.addsitedir() > One other thing that hopefully isn't off topic is the idea of scanning for > imports in general. Does it at all seem logical to have an option for > python to have zero scanning to load a module? After all if you really know > the path to a module, why do you need to scan anything first to find it? well if it's not loaded already, you have to find it don't you ? And you don't know where it is, you have to locate it (see imporlib and pep 302) But for me that's another story, than locating the metadata info of an installed package. Tarek

7 13