Mailman 3 May 2011 - Distutils-SIG

Distribute 0.6.17 incoming
by Tarek Ziadé May 26, 2011

May 26, 2011

Hi I am going to release 0.6.17 this week-end, with a few fixes, most important ones: 1 - python 3.2.1 compat 2 - "ValueError: invalid literal for int() with base 10" during download - https://bitbucket.org/tarek/distribute/issue/196 3 - pkg_resources sandboxing issue - https://bitbucket.org/tarek/distribute/issue/205 If you see anything that you'd like to be fixed in this release, please point me a bug or a patch today or tomorrow. Cheers Tarek -- Tarek Ziadé | http://ziade.org

1 0

Re: [Distutils] distribute's sandboxing doesn't preserve working_set; leads to setup_requires problems
by P.J. Eby May 23, 2011

May 23, 2011

At 11:28 AM 5/22/2011 -0700, chiggsy wrote: >Are people still using setuptools? Yes. Over the last 9 hours alone, the 0.6 development snapshot version (0.6c12dev_r88795) was downloaded from over 100 unique IPs. They most likely represent people manually upgrading to the latest version, since the user agents are mostly older setuptools versions, like 0.6c5, 0.6c9 and 0.6c11. > I thought that distribute was the new way forward...? Not really. Unless you're using Python 3, or you want different default options from setuptools, there's little advantage to using distribute. (It also includes bugs that setuptools does not.) In addition, the announced direction of distribute is that they're replacing it with the new "packaging" project, formerly known as distutils2. Which means, again, that outside of Python 3, there's no compelling reason to switch; you might as well wait for "packaging" to roll around. So, all the hype was pretty much just that: hype and FUD-slinging.

3 2

distribute's sandboxing doesn't preserve working_set; leads to setup_requires problems
by Erik Bray May 22, 2011

May 22, 2011

Hello all, I've got a tricky problem I'm trying to deal with. Here's the scenario: I'm trying to build a package that has two requirements in setup_requires; let's say `setup_requires = ['package_A', 'package_B']`. The problem is that "package_B" also contains "package_A" in its own setup_requires. What happens when I do an install/build is that package_B is downloaded and installed--in the process it also downloads and installs package_A in its sandbox. This wouldn't be a problem except that the sandboxed temp install of package_A is left in pkg_resources.working_set.entries, and so it's assumed package_A is already installed, and the main install doesn't try to fetch it. However, when it goes to import from package_A, I get an import error (because the sandbox it was installed in has since been deleted). If I reverse the order it doesn't work either for a different, but related problem. package_A gets installed into the cwd and is added to pkg_resources.working_set. When package_B is installed it uses the existing package_A installation, so that's fine. But then, due to some complicated interplay, package_A never gets added to sys.path. I'd consider this a defect, though I'm wondering if there's something I could do differently to avoid this situation. Thanks, Erik

4 5

symlinks in sources
by Wichert Akkerman May 18, 2011

May 18, 2011

I am trying to figure out the intended behaviour of dealing with symlinks in package sources. My use case is that I have a number of package implementation web things, and they tend to have an interactive (static) prototype parts of which are reused directly in the application. The filesystem structure for those packages is one of two options: 1. Prototype is at the toplevel of the source. For example: Prototype/index.html Prototyle/style/main.css setup.py MANIFEST.in src/namespace/__init__.py src/namespace/templates/index.html src/namespace/templates/style -> ../../../Prototype/style 2. Prototype is at outside the source. For example: Prototype/index.html Prototyle/style/main.css buildout/bootstrap.py buildout/buildout.cfg buildout/src/mypackage/setup.py buildout/src/mypackage/MANIFEST.in buildout/src/mypackage/src/namespace/__init__.py buildout/src/mypackage/src/namespace/templates/index.html buildout/src/mypackage/src/namespace/templates/style -> ../../../../../../Prototype/style My goal is to be able to create an sdist for my package and upload that to pypi, and when people install that namespace/templates/style/main.css must exist. Currently this does not appear to be possible. The problems I see are: a) symlinks are skipped by distutils b) if you use a file finder plugin which traverses the symlink and reports the files they end up twice in the sdist: once for the Prototype and once inside the package. They second one is stored as a link inside the sdist, but that link is not unpacked when installing from the sdist and the files go missing. Trying to analyse things a bit I see a number of possible scenarios for symlinks: i) symlink pointing to file inside the packgage ii) symlink pointing to directory inside the packgage iii) symlink pointing to file outside the packgage, but in SCM iv) symlink pointing to directory outside the packgage, but in SCM v) symlink pointing to something outside package and not managed by SCM My expectation is that i and ii work out of the box, iii and iv should work if you have a file finder plugin for setuptools that traverses the symlink, and v to not work. Is that expectation reasonable? Wichert.

1 1

Looking for advice on distutils/dist.py and distutils.cfg
by Bill Shipman May 18, 2011

May 18, 2011

Good evening! I'm looking for some direction on a compiler problem. As per the instructions at http://www.pdynamo.org/mainpages/installation/windows.html I am creating the file distutils/distutils.cfg which has 2 lines, **************** [build] compiler=mingw32 **************** as per distutils/dist.py I've also added an identical file setup.cfg in the installation directory of this library. Thus far it always tries to compile using the Visual Studio 9's C compiler when I run python Install.py I am awaiting advice from the pdynamo group but I need to move on this quickly. I'm using python 2.6.6 on Windows 7. I have been advised that pdynamo will not compile with 64bit python. The guy who maintains their Windows installation guide sent me revised instructions for Win7 which he says works fine for him. Any advice would be much appreciated. Thanks Bill

1 0

in search of graceful co-routines
by Chris Withers May 18, 2011

May 18, 2011

Hi All, I'm looking for a graceful pattern for the situation where I have a provider of a sequence, the consumer of a sequence and code to moderate the two, and where I'd like to consumer to be able to signal to the provider that it hasn't succeeded in processing one element in the queue. So, I'd want the controlling code to look a lot like: for item in provider: try: consumer.handleItem(self) except: provider.failed(item) Now, since the sequence is long, and comes from a file, I wanted the provider to be an iterator, so it occurred to me I could try and use the new 2-way generator communication to solve the "communicate back with the provider", with something like: for item in provider: try: consumer.handleItem(self) except: provider.send('fail') else: provider.send('succeed') ..but of course, this won't work, as 'send' causes the provider iteration to continue and then returns a value itself. That feels weird and wrong to me, but I guess my use case might not be what was intended for the send method. Anyway, I wonder how other people would write this? (I'm particularly interested in a sane way to use the two way communication that PEP 342 introduced) cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

2 3

Option --show-response not working properly when uploading to PyPI
by Roy Hyunjin Han May 17, 2011

May 17, 2011

Hi, When I try to upload a package to PyPI using the --show-response option, I get the following result. python setup.py sdist upload --show-response Python 2.7 (r27:82500, Sep 16 2010, 18:03:06) [GCC 4.5.1 20100907 (Red Hat 4.5.1-3)] on linux2 Traceback (most recent call last): File "setup.py", line 31, in <module> zip_safe=True) File "/usr/lib/python2.7/distutils/core.py", line 152, in setup dist.run_commands() File "/usr/lib/python2.7/distutils/dist.py", line 953, in run_commands self.run_command(cmd) File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/usr/lib/python2.7/distutils/command/upload.py", line 60, in run self.upload_file(command, pyversion, filename) File "/usr/lib/python2.7/distutils/command/upload.py", line 189, in upload_file self.announce('-'*75, result.read(), '-'*75) TypeError: announce() takes at most 3 arguments (4 given) Please CC me if you are responding to this message. Thanks, RHH

2 2

[issue130] Setuptools fails to detect Python2.7 install, then provides useless dialog
by Paul Makepeace May 16, 2011

May 16, 2011

New submission from Paul Makepeace <paulm+python(a)paulm.com>: I'm attempting to install setuptools with both 2.6 & 2.7 .msi Midway thru' I get a modal complaining about not finding Python in the registry (I have a stock install so this is puzzling). Python is in C:\Python27 Upon 'OK'ing that dialog I get this useless form; see attached. Can't proceed. ---------- files: setuptools-fail-windows.PNG messages: 626 nosy: paulm priority: bug status: unread title: Setuptools fails to detect Python2.7 install, then provides useless dialog Added file: http://bugs.python.org/setuptools/file77/setuptools-fail-windows.PNG _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue130> _______________________________________________

1 0

Geraldo Reports + Buildout
by João Alfredo May 14, 2011

May 14, 2011

Hi everybody, I'm not sure if this is a geraldo issue or a buildout issue but here we go. I'm trying to include geraldo into my project buildout but it fails to build with the following error: File "/Users/joaoalf/Dropbox/Projetos/dx.nfe/eggs/setuptools-0.6c12dev_r88795-py2.7.egg/setuptools/sandbox.py", line 64, in <lambda> File "setup.py", line 12, in <module> package_dir={'': 'src'}, File "/var/folders/Fa/Faj+MzOzGuWUpLWQhPYR+++++TI/-Tmp-/easy_install-LmafwR/Geraldo-0.4.12-stable/geraldo/__init__.py", line 56, in <module> File "/var/folders/Fa/Faj+MzOzGuWUpLWQhPYR+++++TI/-Tmp-/easy_install-LmafwR/Geraldo-0.4.12-stable/geraldo/base.py", line 8, in <module> ImportError: No module named reportlab.lib.units An error occurred when trying to install Geraldo 0.4.12-stable. Look above this message for any errors that were output by easy_install. While: Installing Geraldo. Getting distribution for 'Geraldo'. Error: Couldn't install: Geraldo 0.4.12-stable and here is my buildout.cfg: [buildout] develop = . parts = xmlsec Geraldo PySPED dx.nfe [xmlsec] recipe = hexagonit.recipe.cmmi url = http://www.aleksey.com/xmlsec/download/xmlsec1-1.2.18.tar.gz [Geraldo] recipe = zc.recipe.egg eggs = reportlab Geraldo [PySPED] recipe = gitrecipe repository = https://github.com/aricaldeira/PySPED.git [dx.nfe] recipe = zc.recipe.egg scripts = dxnfe interpreter = py eggs = zope.interface zope.component zope.event lxml PyXMLSec src = src/dx/nfe reportlab is installed into my buildout eggs directory but geraldo seens to miss it. Can anyone tell me how to fix it? Thanks in advance. João Alfredo -- João Alfredo <ermitaoj(a)gmail.com>

2 2

Buildout status
by Jim Fulton May 12, 2011

May 12, 2011

Buildout has become too complex for me to maintain. Two factors in particular have increased it's complexity to the breaking point, the isolation machinery introduced in 1.5 and the code to support the fork of setuptools. Let me be clear about 1.5: I really *really* appreciate the effort Gary Poster put in to that release. I don't fault his effort, given it's goals, I've just decided that the goals were too ambitious. I recently released 2.0.0a1 for Python 3. Not all tests pass under Python 2 or 3, but enough pass to make this usable with Python 3. The next phase of work will probably involve responding to problems people report with this release. (So far, it's been much quieter than I expected.) After that, I'll get going on the version 2 release in earnest. In the mean time, people will have some time to respond to what I say next, which may be controversial. :) While the current release of buildout 2 has all the features from 1.5, future releases will not. Buildout has to get simpler, or someone else has to take over maintenance. Assuming the former, I plan to eliminate some high maintenance features, including: - Support for multiple Python interpreters within a single buildout - Partial isolation from site packages and site.py Buildout will have an "isolated" mode. In this mode, it will exclude directories from the path that are added by site.py. (I'm not certain what the default should be. I previously thought buildout should switch to being isolated by default, but given the popularity of using buildout with virtualenv, I'm leaning towards making isolation optional.) z3c.recipe.scripts will be spun off to a separate project along with it's support code currently living in the zc.buildout package. I'll to whatever I can, by providing hooks, to support this recipe, but the maintenance of this feature has to move out of buildout. - Support for both setuptools and distribute I'm going to support one, or the other, or neither. I'm in a tough spot. Distribute, which was created because setuptools wasn't being maintained, is no longer being maintained, except there was a recent release. Setuptools, which is being maintained, doesn't work with Python 3. (I was thinking about forking distribute to eliminate the dependency, but after further consideration, I don't think that's a good idea, as one of these is needed to build source releases that depend on them.) My current leaning is toward porting setuptools to 2&3 and supporting only setuptools. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton

7 12