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'?
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
-----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-----
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>
_______________________________________________
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
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>
_______________________________________________
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
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
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