At 11:40 PM 4/1/2008 -0500, Dave Peterson wrote:
I've previously volunteered Enthought to do about the same thing (except
to include svn with the Trac instance) but there wasn't much response
beyond Jeff Rush saying he was already setting one up, and the response
by Phillip to use the python dev
Further, I
assert that there are a greater number of build tools which do not support
cross-compilation, but will build natively on x64 and expect 'PCBuild'
to have libraries they can link with to create an x64 binary.
I'm with Martin on this one as well I think. If I understand correctly,
Hi,
I have just out-clevered myself using setuptools and virtualenv:
* install foo using python setup.py develop (foo being ipython).
* download some module bar you want to work on in an isolated environment
* create this isolated environment using virtualenv bar
* in the isolated
Hi,
I have just out-clevered myself using setuptools and virtualenv:
* install foo using python setup.py develop (foo being ipython).
* download some module bar you want to work on in an isolated environment
* create this isolated environment using virtualenv bar
* in the isolated
On Wed, Apr 2, 2008 at 5:31 AM, Gael Varoquaux
[EMAIL PROTECTED] wrote:
Hi,
I have just out-clevered myself using setuptools and virtualenv:
* install foo using python setup.py develop (foo being ipython).
* download some module bar you want to work on in an isolated environment
*
Gael Varoquaux wrote:
I have just out-clevered myself using setuptools and virtualenv:
* install foo using python setup.py develop (foo being ipython).
* download some module bar you want to work on in an isolated environment
* create this isolated environment using virtualenv bar
Phillip J. Eby wrote:
At 11:40 PM 4/1/2008 -0500, Dave Peterson wrote:
I've previously volunteered Enthought to do about the same thing (except
to include svn with the Trac instance) but there wasn't much response
beyond Jeff Rush saying he was already setting one up, and the response
by
Hi.
I ran into a problem with zc.buildout while upgrading a customers
buildout and wondered if the problem I encountered is a general one.
The buildout in question had one recipe pinned down to an exact version
as in:
[buildout]
parts =
plone
[plone]
recipe = plone.recipe.plone==3.0.2
On Apr 2, 2008, at 3:44 PM, Hanno Schlichting wrote:
Hi.
I ran into a problem with zc.buildout while upgrading a customers
buildout and wondered if the problem I encountered is a general one.
The buildout in question had one recipe pinned down to an exact
version
as in:
[buildout]
I think this is fine; we don't really have a notion of compiling for a
native platform, nor is the build machine's architecture factored into
the equation.
Actually, I think it is slightly. IIUC, the AMD64 build currently assumes
it can execute x86 executables in various places. To fix this,
Even installing shortcuts doesn't need to munge the registry! But
regardless, you seem to be arguing that setuptools should morph into a
full-blown, general purpose installer for python build apps, capable of
doing all kinds of platform specific things which any app may desire - and
while I don't
Hi Mark,
Shortcuts don't, but file associations to those shortcuts do (at least
to the best of my understanding,) adding paths does, etc. I agree that
a library (extensions or no) doesn't need to do these things. But
anything targeted at an end-user on Windows has a reasonable chance of
On Wed, Apr 02, 2008 at 06:32:13PM -0500, Dave Peterson wrote:
Shortcuts don't, but file associations to those shortcuts do (at least to
the best of my understanding,) adding paths does, etc. I agree that a
library (extensions or no) doesn't need to do these things. But anything
13 matches
Mail list logo
