2011/3/19 Adam GROSZER <agroszer(a)gmail.com>:
> As Jim wants to dump setuptools support from buildout, ...
I don't want to, and won't until it gets too painful to support
both. I just suspect that time is drawing near.
I can also foresee a time at which buildout stops using either. That
might be the best path for buildout....wow, the more I think of that,
the more appealing it seems. Replacing use of setuptools/distribute
could be a really nice project for a certain upcoming German buildout
This alternative approach (with a symlink and config file) sounds pretty good to me as well after our discussion at the sprints. The downsides I see:
1. Cross-platform inconsistency. Windows virtualenvs would be isolated from system python binary upgrades, *nix would not (some, like Brandon, consider this isolation a feature, so maybe *nix should allow that option too?) On the whole this doesn't seem like a big issue.
2. There would be no way to set LD_LIBRARY_PATH to include the virtualenv prior to execution of python. To be honest, I don't understand why this is needed, as current virtualenv doesn't do it and I haven't seen it break anything (compiled modules work fine in a venv). But people with more experience seemed to think it was needed at our open space discussion last Saturday. Perhaps someone can clarify what specifically breaks without this?
I'll dive into this approach and see what I can achieve.
I'd also appreciate feedback from Tarek or others familiar with the new sysconfig module about my changes there. Something along those lines will I think be needed with either approach, but I'm almost wondering if a new "virtual" install scheme would be a better approach?
Sent from my Android phone
----- Reply message -----
From: "Vinay Sajip" <vinay_sajip(a)yahoo.co.uk>
Date: Wed, Mar 16, 2011 6:13 pm
Subject: [Distutils] reservations about pythonv
Barry Warsaw <barry <at> python.org> writes:
> Here at the sprints we talked about several possible options, the details of
> which of course will have to be hashed out. There will also be cross platform
> considerations. I think on *nix at least, it would be nice if a symlink and
> configuration file were enough to trigger the virtualenv behavior.
I feel that this approach definitely has potential to be the most useful and
practical. There's no reason for a separate executable if Python itself
incorporates the virtual environment functionality, which is mostly about
setting paths and environment variables.
> For example, if I have a local 'python' symlinked to the real executable, with
> a pythonv.conf file next to it, the virtual environment would be enabled. The
> real Python binary would adjust its behavior in that case to know where the
> standard library was, but also use the locally installed packages. Anyway,
> that's how I'd *like* it to work on *nix, but it may have to work differently
> on Windows, and it may have to work differently if environment variables have
> to be set.
Even if on Windows you have to copy rather than symlink, that could just be the
main Python executable, which is not prohibitively large since the core of
Python is in pythonX.Y.dll.
Distutils-SIG maillist - Distutils-SIG(a)python.org
I'd appreciate some hints how to run the tests of
and how to "test-drive" it.
I want to check/fix the bug with win-amd64.exe's.
That means I need to be able to somehow run
Quote of the day:
Is this really happening?
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
Update your setuptools to 0.6c12dev-r88975 for the fix.
(If you're using a forked setuptoools, you'll need to uninstall it
first so it doesn't block your update.)
At 10:08 PM 3/28/2011 +0700, Hoang Xuan Phu wrote:
>Just today I'm using easy_install to install mechanize and it is
>failing with the error "ValueError: invalid literal for int() with
>base 10: '382727, 382727'". By reading the source code and looking
>at the headers I see that the server is returning 2 Content-Length
>headers (same value, 382727), which is turned intoÂ '382727,
>382727'. Fixing this should be very easy and I can do it then submit
>a patch. I'm just wondering, as distutils seem to be in a forking
>process, what's the best way to solve this?
easy_install -U setuptools will update you to a version that fixes
this, as I've already checked in a fix.
Just today I'm using easy_install to install mechanize and it is failing
with the error "ValueError: invalid literal for int() with base 10: '382727,
382727'". By reading the source code and looking at the headers I see that
the server is returning 2 Content-Length headers (same value, 382727), which
is turned into '382727, 382727'. Fixing this should be very easy and I can
do it then submit a patch. I'm just wondering, as distutils seem to be in a
forking process, what's the best way to solve this?
Hoàng Xuân Phú
New submission from Tres Seaver <tseaver(a)palladion.com>:
The attached patch adds a '--with-test-requirements' / '-t' option to the 'develop' command: the rationale is that when developing a package, one should
be able to run the tests without polluting the local checkout directory with
the eggs specified by its 'tests_require': those eggs should be installed just
as the other ones mandated by 'install_requires'.
I would actually prefer to make this behavior the default, perhaps with a
command-line-switch to disable it, but think that backward compatibility
trumps that itch.
nosy: pje, tseaver
title: Add support for installing test requirements to 'develop' command
Added file: http://bugs.python.org/setuptools/file76/setuptools-0.6-develop-with_test_r…
Setuptools tracker <setuptools(a)bugs.python.org>
i'd like to propose making the work-flow of creating releases by just
pushing vcs tags to a ci system as easy as possible
personally all i ever want to do to release a new version is::
$vcs tag $version
currently that would require various nasty hacks to get the version
meta-data static on sdist and to grab the version number in a setup hook
there are various ways to ease this, the ones i imagined are
a) provide a hook to get the version, make the version static on
pro: straightforward, simple
cons: kind of a hack
b) provide support for multiple setup-hooks and support for command
pro: generic way to do it
cons: needs more code, more stuff in setup.cfg