Re: [pypy-dev] [pypy-svn] r74850 - in pypy/branch/sys-prefix/lib: . pypy1.2 pypy1.2/lib_pypy pypy1.2/lib_pypy/app_test pypy1.2/lib_pypy/ctypes_config_cache pypy1.2/lib_pypy/test2
Hm. I might be missing something, but I thought sys.prefix is only meant for stuff after installation. If this is true (my CPython trunk build has sys.prefix == '/usr/local'), then modifying source checkout does not make any sense, since it's only about installation (which we don't really support anyway). On Fri, May 28, 2010 at 7:53 AM, <antocuni@codespeak.net> wrote:
On Sat, May 29, 2010 at 11:32 -0600, Maciej Fijalkowski wrote:
I think the idea is to make sys.prefix (and thus virtualenv) work even with a translation in a checkout, i.e. not forcing to copy things to another location (which virtualenv partly does on its own). Moreover, keeping app-level modules (and maybe pypy/module at some point) outside the main (interpreter, objspaces, translation and JIT) PyPy tree makes sense to me. e.g. pypy/lang would probably not need to access anything outside such a pypy tree, for example, or am i mistaken? best, holger
Hi holger, On 29/05/10 22:25, holger krekel wrote:
yes
I agree that keeping app-level modules out of pypy is a good idea (this is what I'm doing it, of course :-)), but I don't get what does the reference to pypy/lang mean in this context. ciao, Anto
On Sat, May 29, 2010 at 23:59 +0200, Antonio Cuni wrote:
pyrolog for example doesn't use lib_pypy or pypy/module, does it? holger
On Sun, May 30, 2010 at 00:38 +0200, holger krekel wrote:
sorry, i meant prolog, gameboy, etc ... i.e. the projects in pypy/lang holger
On 30/05/10 00:43, holger krekel wrote:
pyrolog for example doesn't use lib_pypy or pypy/module, does it?
sorry, i meant prolog, gameboy, etc ... i.e. the projects in pypy/lang
yes, indeed. That's why I think it's a good idea to move pypy/lib outside pypy.
Hi Holger, On Sat, May 29, 2010 at 10:25:21PM +0200, holger krekel wrote:
makes sense to me. e.g. pypy/lang would probably not need to access anything outside such a pypy tree, for example, or am i mistaken?
I guess you missed the fact that pypy/lang was moved away from the pypy trunk altogether. Apart from that, you are right: one point of view would be to move pypy/module into /svn/pypy/lang/pypy or something like that. In practice I don't really see the point to increase confusion to that level :-/ Armin
On Sun, May 30, 2010 at 12:16 +0200, Armin Rigo wrote:
sure, it is svn/pypy/lang as opposed to svn/pypy/trunk - it was actually my point, see the other mail :)
Sure, I don't see the need for such an extreme - would complicate working for most people involved with PyPy at the moment. However, going for separating things incrementally if there are other supporting reasons (in this case making sys.prefix work inline in a checkout) makes sense to me. best, holger
Hi Holger, On Sun, May 30, 2010 at 12:25:07PM +0200, holger krekel wrote:
Ah, sorry. I understood it as meaning "svn/pypy/trunk/pypy/lang", because you are talking in the same mail about both "pypy/lang" and "pypy/module", in the second case with the meaning "svn/pypy/trunk/pypy/module".
I don't think there is any relationship between sys.prefix and the location of pypy/module (that's what I was talking about, sorry if it was unclear). A bientot, Armin.
On Sun, May 30, 2010 at 12:36 +0200, Armin Rigo wrote:
Probably right, and indeed, i was talking primarily about pypy/lib -> lib_pypyXYZ, the change that Maciej questioned. Btw, I actually wonder about how cpyext, sys.prefix and compilation after-install (possibly in a virtualenv) interact. Mabe not of concern for the immediate release but maybe good to know already. cheers, holger
What's precisely the point of having pypy version number there? On Sun, May 30, 2010 at 4:51 AM, holger krekel <holger@merlinux.eu> wrote:
Hi Maciek, On 29/05/10 19:32, Maciej Fijalkowski wrote:
you are partly right. In CPython, sys.prefix is just an hard-coded string that represent what was passed to ./configure; tools like virtualenv use it to find the directories containing the stdlib, include files, etc. on the filesystem (I'm not sure it's an entirely good idea, but this is the state of the things and we have to face it). However, nothing prevents the interpreter to set sys.prefix dynamically, e.g. by searching for the directory that contains the stdlib in some location relative to the pypy-c binary; this is what pypy-c does it already to set sys.path. The point of this branch is both: 1) to make it easier to install pypy system-wide: it will be enough to copy pypy-c in /usr/bin and lib/pypy1.2 in /usr/lib (and of course we can automate this with a script, if we want) 2) as holger pointed out, to make it possible to use virtualenv *without* having to install pypy system-wide (which you cannot do with cpython, for example): this will be possible because the directory hierarchy of the svn checkout is designed in a way that setting sys.prefix to the the root of the svn checkout will "just work" ciao, Anto
My concern is mostly that we should not over engineer things and be smarter than CPython (at least in this respect). There is a whole variety of reasons why it would not work in the end. Point 2) talks about superset of CPython funcionality. How for example this would work with compiled cpython extensions that has setup.py install run? On smaller issue, I don't like pypy1.2. Both because it contains a dot and because it contains a revision number. Why we need that? Cheers, fijal On Sat, May 29, 2010 at 3:57 PM, Antonio Cuni <anto.cuni@gmail.com> wrote:
On 30/05/10 00:08, Maciej Fijalkowski wrote:
My concern is mostly that we should not over engineer things and be smarter than CPython (at least in this respect).
well, if we want sys.prefix we *need* to be smarter than CPython, as we don't have any ./configure where take it from. The alternative would be to pass --prefix to translate.py: do you *really* want to do it?
There is a whole variety of reasons why it would not work in the end.
like?
if you use virtualenv, there should be no problem, as it recreates the whole environment needed. If you are talking about running ./translator/goal/pypy-c /my/extension/setup.py install, well, in that case I guess that what happens is just that your extension will be installed inside pypy-trunk/lib/pypy1.2/site-packages or some path like this. Well, too bad for you, I would say.
On smaller issue, I don't like pypy1.2. Both because it contains a dot and because it contains a revision number. Why we need that?
CPython has the standard lib in $PREFIX/lib/python2.6, so for consistency we want ours to reside in $PREFIX/lib/pypy1.2. I know, the drawback of this is that we need to manually rename it every time we change version number, but it's also true that it does not happens often. If you have an alternative solution, I'd like to hear that. Note that I don't think that "don't care about using virtualenv from trunk" is a good alternative solution :-). ciao, Anto
On Sat, May 29, 2010 at 11:32 -0600, Maciej Fijalkowski wrote:
I think the idea is to make sys.prefix (and thus virtualenv) work even with a translation in a checkout, i.e. not forcing to copy things to another location (which virtualenv partly does on its own). Moreover, keeping app-level modules (and maybe pypy/module at some point) outside the main (interpreter, objspaces, translation and JIT) PyPy tree makes sense to me. e.g. pypy/lang would probably not need to access anything outside such a pypy tree, for example, or am i mistaken? best, holger
Hi holger, On 29/05/10 22:25, holger krekel wrote:
yes
I agree that keeping app-level modules out of pypy is a good idea (this is what I'm doing it, of course :-)), but I don't get what does the reference to pypy/lang mean in this context. ciao, Anto
On Sat, May 29, 2010 at 23:59 +0200, Antonio Cuni wrote:
pyrolog for example doesn't use lib_pypy or pypy/module, does it? holger
On Sun, May 30, 2010 at 00:38 +0200, holger krekel wrote:
sorry, i meant prolog, gameboy, etc ... i.e. the projects in pypy/lang holger
On 30/05/10 00:43, holger krekel wrote:
pyrolog for example doesn't use lib_pypy or pypy/module, does it?
sorry, i meant prolog, gameboy, etc ... i.e. the projects in pypy/lang
yes, indeed. That's why I think it's a good idea to move pypy/lib outside pypy.
Hi Holger, On Sat, May 29, 2010 at 10:25:21PM +0200, holger krekel wrote:
makes sense to me. e.g. pypy/lang would probably not need to access anything outside such a pypy tree, for example, or am i mistaken?
I guess you missed the fact that pypy/lang was moved away from the pypy trunk altogether. Apart from that, you are right: one point of view would be to move pypy/module into /svn/pypy/lang/pypy or something like that. In practice I don't really see the point to increase confusion to that level :-/ Armin
On Sun, May 30, 2010 at 12:16 +0200, Armin Rigo wrote:
sure, it is svn/pypy/lang as opposed to svn/pypy/trunk - it was actually my point, see the other mail :)
Sure, I don't see the need for such an extreme - would complicate working for most people involved with PyPy at the moment. However, going for separating things incrementally if there are other supporting reasons (in this case making sys.prefix work inline in a checkout) makes sense to me. best, holger
Hi Holger, On Sun, May 30, 2010 at 12:25:07PM +0200, holger krekel wrote:
Ah, sorry. I understood it as meaning "svn/pypy/trunk/pypy/lang", because you are talking in the same mail about both "pypy/lang" and "pypy/module", in the second case with the meaning "svn/pypy/trunk/pypy/module".
I don't think there is any relationship between sys.prefix and the location of pypy/module (that's what I was talking about, sorry if it was unclear). A bientot, Armin.
On Sun, May 30, 2010 at 12:36 +0200, Armin Rigo wrote:
Probably right, and indeed, i was talking primarily about pypy/lib -> lib_pypyXYZ, the change that Maciej questioned. Btw, I actually wonder about how cpyext, sys.prefix and compilation after-install (possibly in a virtualenv) interact. Mabe not of concern for the immediate release but maybe good to know already. cheers, holger
What's precisely the point of having pypy version number there? On Sun, May 30, 2010 at 4:51 AM, holger krekel <holger@merlinux.eu> wrote:
Hi Maciek, On 29/05/10 19:32, Maciej Fijalkowski wrote:
you are partly right. In CPython, sys.prefix is just an hard-coded string that represent what was passed to ./configure; tools like virtualenv use it to find the directories containing the stdlib, include files, etc. on the filesystem (I'm not sure it's an entirely good idea, but this is the state of the things and we have to face it). However, nothing prevents the interpreter to set sys.prefix dynamically, e.g. by searching for the directory that contains the stdlib in some location relative to the pypy-c binary; this is what pypy-c does it already to set sys.path. The point of this branch is both: 1) to make it easier to install pypy system-wide: it will be enough to copy pypy-c in /usr/bin and lib/pypy1.2 in /usr/lib (and of course we can automate this with a script, if we want) 2) as holger pointed out, to make it possible to use virtualenv *without* having to install pypy system-wide (which you cannot do with cpython, for example): this will be possible because the directory hierarchy of the svn checkout is designed in a way that setting sys.prefix to the the root of the svn checkout will "just work" ciao, Anto
My concern is mostly that we should not over engineer things and be smarter than CPython (at least in this respect). There is a whole variety of reasons why it would not work in the end. Point 2) talks about superset of CPython funcionality. How for example this would work with compiled cpython extensions that has setup.py install run? On smaller issue, I don't like pypy1.2. Both because it contains a dot and because it contains a revision number. Why we need that? Cheers, fijal On Sat, May 29, 2010 at 3:57 PM, Antonio Cuni <anto.cuni@gmail.com> wrote:
On 30/05/10 00:08, Maciej Fijalkowski wrote:
My concern is mostly that we should not over engineer things and be smarter than CPython (at least in this respect).
well, if we want sys.prefix we *need* to be smarter than CPython, as we don't have any ./configure where take it from. The alternative would be to pass --prefix to translate.py: do you *really* want to do it?
There is a whole variety of reasons why it would not work in the end.
like?
if you use virtualenv, there should be no problem, as it recreates the whole environment needed. If you are talking about running ./translator/goal/pypy-c /my/extension/setup.py install, well, in that case I guess that what happens is just that your extension will be installed inside pypy-trunk/lib/pypy1.2/site-packages or some path like this. Well, too bad for you, I would say.
On smaller issue, I don't like pypy1.2. Both because it contains a dot and because it contains a revision number. Why we need that?
CPython has the standard lib in $PREFIX/lib/python2.6, so for consistency we want ours to reside in $PREFIX/lib/pypy1.2. I know, the drawback of this is that we need to manually rename it every time we change version number, but it's also true that it does not happens often. If you have an alternative solution, I'd like to hear that. Note that I don't think that "don't care about using virtualenv from trunk" is a good alternative solution :-). ciao, Anto
participants (4)
-
Antonio Cuni -
Armin Rigo -
holger krekel -
Maciej Fijalkowski