Carl Meyer oddbird.net> writes:
> Looks great! I can confirm it works when installed. I'll look into the
> source-build issues.
I've also updated pmv.py at
https://gist.github.com/893507
to be closer to what we want for virtualize.py in the stdlib, so that you can do
python3.3 -m virtualize /
At 02:14 PM 4/1/2011 -0400, Carl Meyer wrote:
But, as I mentioned, the fact that easy_install itself relies on finding
site-packages relative to sys.prefix forces the issue - easy_install
(including existing versions of it) needs to just work.
No, it doesn't, actually.
easy_install only uses s
Carl Meyer oddbird.net> writes:
>
> People tend to create a lot of virtualenvs. I don't think copying the
> entire Python installation is viable (it is slow, and it also would mean
> that security updates to the base standard library would not be
> reflected in the virtualenv).
You're probably
On 03/31/2011 09:21 AM, Vinay Sajip wrote:
> Vinay Sajip yahoo.co.uk> writes:
>
>> I think the problem is occurring because there's incomplete support for
>> running
>> from a source build.
>
> To confirm this, I installed pythonv - and then running pmv.py produces the
> expected result - an
On 03/31/2011 04:12 AM, Vinay Sajip wrote:
> Carl Meyer oddbird.net> writes:
>
>> The logical conclusion of that approach, if you want
>> full compatibility with third-party code, is to just copy the entire
>> Python installation to the new location.
>
> We do want that compatibility, don't we?
Vinay Sajip yahoo.co.uk> writes:
> I think the problem is occurring because there's incomplete support for
> running
> from a source build.
To confirm this, I installed pythonv - and then running pmv.py produces the
expected result - an env with a copied Python which allows you to install stuff
Carl Meyer oddbird.net> writes:
> Hmm, it doesn't seem to be working for me. sys.prefix and
> sys.exec_prefix are still /usr/local using the python binary in my
> "pmv", and sys.virtual_prefix is not set at all, despite env.cfg being
> present and looking as it should.
>
> Oddly when I run the c
Carl Meyer oddbird.net> writes:
> The logical conclusion of that approach, if you want
> full compatibility with third-party code, is to just copy the entire
> Python installation to the new location.
We do want that compatibility, don't we? Using a virtual environment should be a
no-brainer, as
On 03/30/2011 11:23 PM, P.J. Eby wrote:
> At 01:35 PM 3/30/2011 -0400, Carl Meyer wrote:
>> So... it seems to me that we're likely to break _some_ third-party code
>> using sys.prefix regardless of what we do here. My instinct says adding
>> sys.virtual_prefix and leaving sys.prefix alone is the
On 03/30/2011 07:18 PM, Vinay Sajip wrote:
>> So... it seems to me that we're likely to break _some_ third-party code
>> using sys.prefix regardless of what we do here. My instinct says adding
>> sys.virtual_prefix and leaving sys.prefix alone is the better approach,
>> but I'm not very firmly entr
At 01:35 PM 3/30/2011 -0400, Carl Meyer wrote:
So... it seems to me that we're likely to break _some_ third-party code
using sys.prefix regardless of what we do here. My instinct says adding
sys.virtual_prefix and leaving sys.prefix alone is the better approach,
but I'm not very firmly entrenched
Carl Meyer oddbird.net> writes:
> So... it seems to me that we're likely to break _some_ third-party code
> using sys.prefix regardless of what we do here. My instinct says adding
> sys.virtual_prefix and leaving sys.prefix alone is the better approach,
> but I'm not very firmly entrenched in tha
Hi Vinay,
On 03/29/2011 07:00 PM, Vinay Sajip wrote:
>> If we switch to sys.virtual_prefix and leave sys.prefix alone, the
>> danger would be that some installer that's using sys.prefix directly,
>> and ignoring sysconfig.py, would try to install stuff to the global
>> Python installation. But I'm
Carl Meyer 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, whi
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 , and in
> /bin we have a copied, non-installed Python, obtained from absolute
> path . Say we provide the locat
Carl Meyer 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
On Fri, Mar 18, 2011 at 6:35 PM, Carl Meyer wrote:
> On 03/18/2011 05:24 PM, Tres Seaver wrote:
>> Could the config file contain an optional hint for finding the "right"
>> stdlib in cases where the binary copy had been made? I realize that
>> parsing a config file *without* the stdlib is painful
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/18/2011 08:01 PM, Vinay Sajip wrote:
> Hi Carl,
>
>> So, possibilities I see for addressing this:
>>
>> 1. Decide that in real cases of real Python installations, it's so
>> unlikely to happen that we won't worry about it. I think it's possible
Hi Carl,
> So, possibilities I see for addressing this:
>
> 1. Decide that in real cases of real Python installations, it's so
> unlikely to happen that we won't worry about it. I think it's possible
> that this is acceptable; the biggest practical problem is likely to be
> people trying to test
On 03/18/2011 07:22 PM, Éric Araujo wrote:
>> 1. It seems... tempting but ill-advised to make it a "fake" ConfigParser
>> option if in the place where I use it, I'm not actually parsing the file
>> with full ConfigParser semantics. It might work, but then someone tries
>> to get clever with a [DE
> 1. It seems... tempting but ill-advised to make it a "fake" ConfigParser
> option if in the place where I use it, I'm not actually parsing the file
> with full ConfigParser semantics. It might work, but then someone tries
> to get clever with a [DEFAULT] section, or interpolation, or who knows
>
On 03/18/2011 05:24 PM, Tres Seaver wrote:
> Could the config file contain an optional hint for finding the "right"
> stdlib in cases where the binary copy had been made? I realize that
> parsing a config file *without* the stdlib is painful: perhaps looking
> for a line starting with 'stdlib ='
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/18/2011 03:20 PM, P.J. Eby wrote:
> At 02:44 PM 3/18/2011 -0400, Carl Meyer wrote:
>> Apparently (I am Windows-ignorant) recent Windows versions do
>> support symlinks?
>
> Technically, some Windows filesystems can support this. In practice,
>
At 02:44 PM 3/18/2011 -0400, Carl Meyer wrote:
Apparently (I am Windows-ignorant) recent Windows versions do
support symlinks?
Technically, some Windows filesystems can support this. In practice,
no user-visible tools actually support making or using them sanely, AFAIK.
So, I suggest promot
Hi Vinay,
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:
https://bitbucket.org/carljm/cpythonv/issue/6/if-binary-is-copied-prefix-finding-could
The issue is findin
Vinay Sajip yahoo.co.uk> writes:
> On this system I have a local build of Python made from the official default
> branch, which is installed to /usr/local/lib since the system Python is 3.2
> (Ubuntu 11.04 - Natty).
Sorry, I meant to say that the system Python is 2.7 (in /usr). I also have an
of
Carl Meyer oddbird.net> writes:
> This is odd, as the same setup works fine for me with a copied binary
> (I'm on Ubuntu 10.10). If you're willing to do any more debugging on
> this, here's what would be helpful:
I think I know what the problem is: the python executable checks to see where it
wa
On 03/17/2011 03:16 PM, Barry Warsaw wrote:
> I dunno. I tend to think python-ideas are where ideas go to die. ;) I think
> we have general consensus that this is a good idea, and we just need to hash
> out the details. So I personally think python-dev is fine at this point.
Seems like it can
On Mar 17, 2011, at 02:50 PM, Carl Meyer wrote:
>On 03/16/2011 11:04 PM, Barry Warsaw wrote:
>> +1. Time for a PEP?
>
>Working on a draft PEP. I'll push it to bitbucket to make collaboration
>easier - then the next step would be to present the draft on
>python-ideas, if I'm reading PEP 2 correctl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/17/2011 02:50 PM, Carl Meyer wrote:
> On 03/16/2011 11:04 PM, Barry Warsaw wrote:
>> +1. Time for a PEP?
>
> Working on a draft PEP. I'll push it to bitbucket to make collaboration
> easier - then the next step would be to present the draft on
On 03/16/2011 11:04 PM, Barry Warsaw wrote:
> +1. Time for a PEP?
Working on a draft PEP. I'll push it to bitbucket to make collaboration
easier - then the next step would be to present the draft on
python-ideas, if I'm reading PEP 2 correctly?
Carl
__
Hi Vinay,
On 03/17/2011 06:25 AM, Vinay Sajip wrote:
> It seems to work with a symlink but not with a copy. With an empty
> pythonv.conf
> file in ~/projects/vptest:
>
> vinay@eta-natty:~/projects/vptest/bin$ ln -s ~/tools/cpythonv/python
> vinay@eta-natty:~/projects/vptest/bin$ ./python
> Pytho
Carl Meyer oddbird.net> writes:
> work well. Please try it and tell me what I missed!
>
> To try it out, create a directory somewhere with a bin/ subdirectory,
> symlink or copy (it works either way) the python3 binary from an install
> of the pythonv2 branch into bin/, and create lib/python3.3/
On Mar 16, 2011, at 10:33 PM, Carl Meyer wrote:
>I've pushed this symlink/copy binary approach to the "pythonv2" branch
>at http://bitbucket.org/carljm/cpythonv. I was a bit shocked at how easy
>it turned out to be: just a few lines in site.py and the same changes to
>sysconfig.py as previously. N
Hi all,
I've pushed this symlink/copy binary approach to the "pythonv2" branch
at http://bitbucket.org/carljm/cpythonv. I was a bit shocked at how easy
it turned out to be: just a few lines in site.py and the same changes to
sysconfig.py as previously. No changes in C code needed at all. It was
so
35 matches
Mail list logo
