Carl Meyer carl at oddbird.net writes:
Thanks for the additional digging in here. I think your analysis is
right - it actually occurred to me yesterday that this could be the
problem, and I filed a bug to track it here:
3. The fully-reliable fix would be to somehow give the copied binary a
Hi Vinay,
On 03/29/2011 09:45 AM, Vinay Sajip wrote:
I've been thinking about the C-level configuration some more (cpythonv issue
#6). Suppose we have a virtual env at absolute path testenv, and in
testenv/bin we have a copied, non-installed Python, obtained from absolute
path pythonsrc. Say
There seem to be some problems with packages on sourceforge not working with
buildout. Something about sourceforge is sending two content-length
headers. Anything the buildout gurus here can add?
Description of problem. Suggests just eliminating sourceforge from allowed
hosts:
At 04:25 PM 3/29/2011 -0400, Jeff Kunce wrote:
There seem to be some problems with packages on sourceforge not
working with buildout. Something about sourceforge is sending two
content-length headers.
Update your setuptools to 0.6c12dev-r88975 for the fix.
(If you're using a forked
Carl Meyer carl at oddbird.net writes:
In general, I think the copied binary case should be as similar as
possible to the symlinked binary case. Python doesn't dereference
symlinks in setting sys.executable, so in either case sys.executable
will point to the virtual environment's binary,
On Tue, Mar 29, 2011 at 4:54 PM, P.J. Eby p...@telecommunity.com wrote:
Update your setuptools to 0.6c12dev-r88975 for the fix.
Egads, Philip! Do regular version numbers cost more in your neighborhood?
-Fred
--
Fred L. Drake, Jr. fdrake at acm.org
A storm broke loose in my mind.
