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? > Point 2) talks about superset of CPython funcionality. How for example > this would work with compiled cpython extensions that has setup.py > install run? 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 _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
