Re: [pypy-dev] PyPy in Fedora
Ah, ok, didn't read the post in details. You're targeting svn trunk. That has a bit of it's own problems, but it's probably slightly better than using 1.2 On Sat, May 29, 2010 at 9:24 AM, Maciej Fijalkowski fij...@gmail.com wrote: Hello. It's great that fedora is doing that! However, is it possible to delay it until we have 1.2.1 release? It will contain some important bugfixes. On Sat, May 29, 2010 at 8:38 AM, Gianluca Sforna gia...@gmail.com wrote: Fedora is working to include PyPy in the distribution, I guess some of you may be interested in some pointers: Review request for the PyPy package: https://bugzilla.redhat.com/show_bug.cgi?id=588941 Possible feature targeting Fedora 14: https://fedoraproject.org/wiki/Features/PyPyStack Fedora Python SIG: http://fedoraproject.org/wiki/SIGs/Python Cheers G. -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
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
Hi holger, On 29/05/10 22:25, holger krekel 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). yes 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? 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 ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
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
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.c...@gmail.com wrote: Hi Maciek, On 29/05/10 19:32, Maciej Fijalkowski wrote: 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). 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 ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
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
On Sat, May 29, 2010 at 23:59 +0200, Antonio Cuni wrote: On 29/05/10 22:25, holger krekel 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). yes 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? 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. pyrolog for example doesn't use lib_pypy or pypy/module, does it? holger ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
