[pypy-dev] virtualenv support and directory hierarchy
fijall at gmail.com
Fri Jun 18 19:01:44 CEST 2010
I expressed my concerns already, but I'm going to express them once
again, since amaury also said that on IRC.
I really dislike having version number hardcoded in source checkout
for a whole variety of reasons. I don't think need to have virtualenv
working from source checkout is enough to push that through.
How about install script that does that maybe?
On Wed, May 26, 2010 at 8:55 AM, Antonio Cuni <anto.cuni at gmail.com> wrote:
> Hi all,
> I am investigating how to make virtualenv working on pypy and I'm running into
> a couple of issues: the most important one is that virtualenv relies on
> sys.prefix (which does not exists in pypy) to find the standard library, and
> the other is that the standard library of pypy is supposed to be put in
> /usr/share instead of /usr/lib (or /usr/local/*).
> Currently, a pypy installation is supposed to have this structure:
> In such a situation, sys.pypy_prefix is set to '/usr/share/pypy-1.2'.
> I propose to change it in this way:
> where lib-pypy contains what it's now in pypy/lib.
> In such a situation, sys.prefix would be set to '/usr', in a similar way as
> cpython. Also, we should also add a sys.exec_prefix which is meant to be
> always equal to sys.prefix (at least for now).
> (I removed the dash in pypy-1.2 for consistency with cpython, which uses
> something like lib/python2.6).
> Moreover, I would also like virtualenv to work from an svn checkout/source
> tarball of pypy, without any needing of installing it system-wide. To do so,
> we need to find a sensible value for sys.prefix, considering that tools like
> virtualenv suppose to find the stdlib under sys.prefix+'lib/'+something_else.
> So, the proposed new structure is this:
> sys.prefix == '/path/to/pypy-trunk'
> The drawback is that before getting to the real files you have to walk a lot
> of empty directories, and that we should manually change the name of pypy1.2
> each time we increase the version number (not that it happens very often :-)).
> One side-advantage is that in this way we would move pypy/lib outside the main
> pypy package, which is good because it's not really a part of it.
> Finally, we should probably think of where to put the include/ directory (plus
> other that might be needed to build extension), but I'll let cpyext experts to
> say what it's better :-)
> What do you think? Any comment/suggestion/problem that I overlooked?
> pypy-dev at codespeak.net
More information about the Pypy-dev