Distutils-SIG March 2011

distutils-sig@python.org

51 participants
61 discussions

Re: [Distutils] pythonv: let's also make sure the standard Python install includes an "isolated" python

by P.J. Eby

At 05:13 PM 3/17/2011 -0400, Jim Fulton wrote: >I suggest the following: > >Look for argv[0]+'.pythonv' and then for '../pythonv.cfg'. > >So if I've linked the Python executable to ./bin/clean, look for >./bin/clean.pythonv and ./pythonv.cfg. And on Windows, presumably remove the .exe part? or are you saying 'python.exe.pythonv'?

9 years, 4 months

New buildout options: checksums and allow-omitted-checksums

by Thomas Lotze

Hi, two weeks ago I asked about your opinions on a buildout option that enforces specifying (MD5) checksums for all files downloaded through buildout's download utility API. I've been discussing the subject with Christian Theune in the meantime and would like to describe a more concrete proposal now that deals with the questions raised in my previous post: In analogy with version pinning for eggs, two new options could be introduced to the buildout section: - "checksums": This option would name a config section that contains checksums for any number of resources by URL. I suggest a default value of "checksum" for it. Listing some URL with an empty checksum would explicitly express that the checksum for this resource should never be checked. I'm not sure how to structure the contents of the checksums section: URLs are not valid config keys in general (they can contain "=" characters) but I'd still like to be able to rely on the existing mechanism for overriding single options to override single checksums. Mapping arbitrary keys to whitespace-separated pairs of URL and checksum would work but sounds inelegant. - "allow-omitted-checksums": This option would specify whether resources should be downloaded that are not listed in the checksums section. I'd like to use False as this option's default value, meaning that buildout should raise a UserError if a resource is omitted from the checksums section. (Intentionally empty checksums would still be allowed.) In fact, I'm not completely happy about inventing an option with negative semantics but doing it this way is at least consistent with "allow-picked-versions". I'd like to hear other people's opinion on both the general idea and the details. Unless the whole thing gets shot down, I plan to start implementing it on a branch of zc.buildout next week. Thank you. -- Thomas

9 years, 4 months

issues with namespace packages on Debian Squeeze and Python 2.6

by Manlio Perillo

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi. It seems I'm having some trobles with setuptools and namespace packages under Debian Squeeze and Python 2.6. One thing to say about Python 2.6 on Debian Squeeze is that "local" packages are installed under /usr/local/lib/python2.6/dist-packages/. I have tried with system default python 2.5, and namespace packages works. The same when I create a virtual environment with python 2.6. The problem seems to just be with system default python 2.6. I'm using the original setuptools (installed from sources), and not the one provided by Debian. Before trying to dig more into the issue, I would like to know if someone else is experiencing the same problem. Thanks Manlio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1wELgACgkQscQJ24LbaUTtNwCfe5tj21cHc2IpDbDQShoJ+7zb ml8AoI0h9IKuScKE/mZIkKZGbFC5ILka =0sg2 -----END PGP SIGNATURE-----

9 years, 4 months

[issue123] [PATCH] Tolerate responses with multiple Content-Length headers

by Tres Seaver

New submission from Tres Seaver <tseaver(a)palladion.com>: Some servers (e.g., wwwsearch.sourceforge.net) apparently send multiple 'Content-Length' headers, which causes setuptools to barf trying to convert a '<length>, <length>' string to an integer. This bug breaks installing 'mechanize', which lists wwwsearch.sourceforge.net as its Download-URL, and therefore causes a bunch of Zope-related tests to fail (e.g., https://mail.zope.org/pipermail/cmf-tests/2011-March/014576.html ). The attached patch uses 'headers.getheaders('Content-Length')[0] to use only the first value found. ---------- assignedto: pje files: setuptools-multi_content_length.patch messages: 598 nosy: pje, tseaver priority: urgent status: unread title: [PATCH] Tolerate responses with multiple Content-Length headers Added file: http://bugs.python.org/setuptools/file75/setuptools-multi_content_length.pa… _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue123> _______________________________________________

9 years, 4 months

VirtualPython proposal

by d.camata＠gmail.com

Hello all, I've found virtualpython idea in the PSF GSoC page very interesting and I'm looking for Martin v. Lowis to talk about the proposal. I didn't knew where to contact him, so I went to IRC and somebody told me to try here. Regards, -- Douglas Camata Graduando em Ciência da Computação (UENF) Blog: http://blog.douglascamata.net Github: http://github.com/douglasamata Twitter: @douglascamata <http://twitter.com/douglascamata> <http://twitter.com/douglascamata>Skype: douglas_camata ----------------------------------- Linux User #509211

9 years, 4 months

broken buildout tests on windows was: [Zope-dev] Zope Tests: 68 OK, 34 Failed, 6 Unknown

by Adam GROSZER

Hello, >> Subject: FAILED : winbot / zc_buildout_dev py_254_win32 >> From: buildbot at winbot.zope.org >> Date: Sun Mar 20 17:07:28 EDT 2011 >> URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035690.html >> >> Subject: FAILED : winbot / zc_buildout_dev py_265_win32 >> From: buildbot at winbot.zope.org >> Date: Sun Mar 20 17:07:39 EDT 2011 >> URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035691.html >> >> Subject: FAILED : winbot / zc_buildout_dev py_265_win64 >> From: buildbot at winbot.zope.org >> Date: Sun Mar 20 17:07:50 EDT 2011 >> URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035692.html >> >> Subject: FAILED : winbot / zc_buildout_dev py_270_win32 >> From: buildbot at winbot.zope.org >> Date: Sun Mar 20 17:08:00 EDT 2011 >> URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035693.html >> >> Subject: FAILED : winbot / zc_buildout_dev py_270_win64 >> From: buildbot at winbot.zope.org >> Date: Sun Mar 20 17:08:14 EDT 2011 >> URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035694.html > > More weird Windows build failures:: > > > c:\buildslave\zc_buildout_dev_py_254_win32\build>bin\test.exe > - --exit-with-status -1" > 'bin\test.exe' is not recognized as an internal or external command, > operable program or batch file. Bootstrap failed, it just does not exit with the right exitcode. See: http://winbot.zope.org/builders/zc_buildout_dev%20py_270_win32/builds/239/s… Anyone feeling guilty? -- Best regards, Adam GROSZER -- Quote of the day: Zimmerman's Law of Complaints: Nobody notices when things go right.

9 years, 4 months

[issue122] Xcode 4 removes PPC compiler OS X 10.6, setup.py fails installs

by Johannes Lindenbaum

New submission from Johannes Lindenbaum <johanneslindenbaum(a)gmail.com>: Summary: OSX 10.6.x with Xcode 4 installed. Xcode 4 removes the PPC assembler from GCC. I attempted to install Fabric-1.0.0 which depended on pycrypto, during the pycrypto build there was a failure regarding "Broken Pipe". I downloaded the package separately and attempted to do the install there. Same error. I was pointed in the right direction that the broken pipe error was coming from the '-arch ppc' flag during build. Expected Result 10.6.x should not report itself as "universal" when it's no longer possible to compile for PPC. Actual Result Attempted PPC compilation fails. More detail: http://superuser.com/questions/259278/python-2-6-1-pycrypto-2-3-pypi-packag… Let me know if you require more information. Kind Regards, Johannes ---------- messages: 594 nosy: jlindenbaum priority: bug status: unread title: Xcode 4 removes PPC compiler OS X 10.6, setup.py fails installs _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue122> _______________________________________________

9 years, 4 months

pythonv: let's also make sure the standard Python install includes an "isolated" python

by Jim Fulton

Whatever mechanism we end up with, I suggest that a standard python install include an isolated configuration. This is a common use case and should be available without having to create a virtualenv (or whatever) for each project or working directory. I'm very happy to see this work taking place. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton

9 years, 4 months

Fwd: Re: window 64bit madness

by Adam GROSZER

Hello, As Jim wants to dump setuptools support from buildout, would you mind taking a look at this issue for distribute please? -------- Original Message -------- Subject: Re: [Distutils] window 64bit madness Date: Thu, 17 Mar 2011 08:43:17 +0100 From: Adam GROSZER <agroszer.ll(a)gmail.com> To: distutils-sig(a)python.org On 03/16/2011 11:47 PM, P.J. Eby wrote: > At 11:28 AM 3/16/2011 +0100, Adam GROSZER wrote: >> On 03/14/2011 07:50 PM, P.J. Eby wrote: >>> Run "python -c 'import pkg_resources;print >>> pkg_resources.get_build_platform()'" (with the Python interpreter you're >>> using. >> >> D:\install>c:\Python26_64\python.exe >> Python 2.6.6 (r266:84297, Aug 24 2010, 18:13:38) [MSC v.1500 64 bit >> (AMD64)] on win32 >> Type "help", "copyright", "credits" or "license" for more information. >> >>> import pkg_resources;print pkg_resources.get_build_platform() >> win-amd64 >> >>> > > Hm. What's sys.platform? Is it win32? Exactly. > I suspect the problem has to do with all the win32-specificness > scattered through setuptools; I think I know what I need to do to fix it > all, but it'll be a fairly substantial patch; can you help with the > testing if I email you such a patch? Sure thing. -- Best regards, Adam GROSZER -- Quote of the day: Nothing ever built arose to touch the skies unless some man dreamed that it should, some man believed that it could, and some man willed that it must. - Charles F. Kettering

9 years, 4 months

distutils2 Forward Compatibility module

by Erik Bray

Hi all, This is my first post specifically to distutils-sig, though I've had an interest in packaging for a while (having come up with some fairly arcane schemes in the past, where no better alternatives were apparent). At any rate: I'm currently working on a plan to overhaul how a number of my company's projects are packaged and distributed. Right now they all rely on a monkey-patched, hacked up distutils that needs to go away. I'm already on top of that. But seeing as how distutils2 is going to be the "new hotness" I want to plan for at as part of my overhaul. I realize that distutils2 is still in flux, and anything I do now will have to be tweaked as development on it continues. I am fine with this, as I still intend to use Distribute as the primary installation mechanism. But I really like how distutils2 keeps all metadata in the setup.cfg file, and want to start doing that now, so that I don't have to keep two copies of everything. It should be no problem to just have my setup.py read everything it needs out of setup.cfg, but what I'm wondering is if there is already an extension to do this, or will I have to roll my own? It just seems like an obvious thing to have for transitioning to distutils2, and if it doesn't already exist it should (I will of course be happy to contribute). I should note that I don't want distutils2 itself to be a dependency for installing my packages, as it is too unstable, so directly using any machinery built into it is out of the question. Thanks for any comments, Erik

9 years, 4 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Distutils-SIG March 2011