Re: Python
On Fri, Aug 3, 2012 at 12:06 AM, Pedro Giffuni p...@apache.org wrote: Hello guys; FWIW, the update to version 2.7.3 doesnt really bring a big difference wrt 2.6.1 but I dont think we will be able to update python further in a long while because there are extensions out there that depend on Python2. Adding Python3 compatibility is not difficult, I think, but an interesting alternative, that people can try now, would be to build/ship AOO with PyPy : http://pypy.org/ Cheers, Pedro. Since PyPy is built on top of Python, I wonder how will that impact the gcc issue? Also would be interesting to test the pyuno module in PyPy make sure is compatible. Finally I wonder which extension is dependend on Python2 from the PyUNO module?
Re: Python
On 03.08.2012 07:06, Pedro Giffuni wrote: Hello guys; FWIW, the update to version 2.7.3 doesnt really bring a big difference wrt 2.6.1 but I dont think we will be able to update python further in a long while because there are extensions out there that depend on Python2. It has the advantage that 2.7.3 is an official release that we can (and do) download directly from python.org. 2.6.1 is not listed on http://python.org/download/releases/ and does not appear to be an official release. We may be the only ones who use it. -Andre Adding Python3 compatibility is not difficult, I think, but an interesting alternative, that people can try now, would be to build/ship AOO with PyPy : http://pypy.org/ Cheers, Pedro. *From: * Andre Fischer awf@gmail.com; *To: * ooo-dev@incubator.apache.org; *Subject: * Re: Python *Sent: * Thu, Aug 2, 2012 1:18:02 PM On 02.08.2012 14:48, Alexandro Colorado wrote: On 8/2/12, Alexandro Colorado j...@oooes.org javascript:return wrote: The issue was written on the UDK site explaining this issue. http://www.openoffice.org/udk/python/python-bridge.html#faq I already have python installed on my system, why does the office ship another python ? Python itself is shipped with OpenOffice.org, because python must have been compiled with the same C++ compiler as the office itself on all platforms that use the gcc compiler (e.g. Linux, BSD, etc.). On most Unix platforms, no python shared libraries are available by default (though some distributions do so). This would have meant, that python UNO components cannot be executed within the office process. Python component developers need a guaranteed minimum platform which they can rely on. Recognition of a python runtime at the installation system would have been an extremely difficult and time consuming task becausemany different python installation schemes exist. Packagers of OpenOffice.org will create their own packages, for example redhat or debian, without Python. The standard distribution must run on low end systems. Can I use system's python installation ? See here. (http://www.openoffice.org/udk/python/python-bridge.html#replacing) Basically is a lack of support, some dev hours could permanently fix this issue. But someone needs to do it. On 8/2/12, Andre Fischer awf@gmail.com javascript:return wrote: Hi all, Can anybody remind me of why we bring our own Python? Are the reasons still valid after the update to 2.7.3? I just updated main/external_deps.lst to load the tarball from python.org and had almost chosen the windows binary instead of the source tarball. I am now wondering why we don't have a build prerequisite on a pre-installed, standard Python. Thanks, Andre -- Alexandro Colorado OpenOffice.org Español http://es.openoffice.org By the way, I think most distros already make this adjustment using the system python from the openoffice.org-python...deb/rpm. http://rpmfind.net/linux/rpm2html/search.php?query=openoffice.org-pyuno The package just include the libpyuno and objects, but no binary in itself. Thanks for the info. Much appreciated. -Andre
Re: Python
On Fri, Aug 3, 2012 at 2:06 AM, Pedro Giffuni p...@apache.org wrote: Adding Python3 compatibility is not difficult, I think, but an interesting alternative, that people can try now, would be to build/ship AOO with PyPy Whatever change you make make sure you take into account other platforms like OS/2 (yes, there´s an OS/2 port of OO) where Python does not come standard with the OS. FC
Re: Python
Hi Alexandro; From: Alexandro Colorado j...@oooes.org ... Adding Python3 compatibility is not difficult, I think, but an interesting alternative, that people can try now, would be to build/ship AOO with PyPy : http://pypy.org/ Cheers, Pedro. Since PyPy is built on top of Python, I wonder how will that impact the gcc issue? PyPy supports the C API so it should just work by using it as the external python implementation. A quick google search would imply someone did it already. I think it may be an interesting option for packagers but I wouldn't like to bring PyPy into AOO: the build process looks somewhat complex although it's probably more portable that the standard CPython. Also would be interesting to test the pyuno module in PyPy make sure is compatible. According to the PyPy site it is compatible with Python 2.7.2 so it should just work. Finally I wonder which extension is dependend on Python2 from the PyUNO module? There are probably a lot of scripts out there? Unfortunately it doesn't look like pyuno is very popular. Pedro.
Re: Python
The issue was written on the UDK site explaining this issue. http://www.openoffice.org/udk/python/python-bridge.html#faq I already have python installed on my system, why does the office ship another python ? Python itself is shipped with OpenOffice.org, because python must have been compiled with the same C++ compiler as the office itself on all platforms that use the gcc compiler (e.g. Linux, BSD, etc.). On most Unix platforms, no python shared libraries are available by default (though some distributions do so). This would have meant, that python UNO components cannot be executed within the office process. Python component developers need a guaranteed minimum platform which they can rely on. Recognition of a python runtime at the installation system would have been an extremely difficult and time consuming task becausemany different python installation schemes exist. Packagers of OpenOffice.org will create their own packages, for example redhat or debian, without Python. The standard distribution must run on low end systems. Can I use system's python installation ? See here. (http://www.openoffice.org/udk/python/python-bridge.html#replacing) Basically is a lack of support, some dev hours could permanently fix this issue. But someone needs to do it. On 8/2/12, Andre Fischer awf@gmail.com wrote: Hi all, Can anybody remind me of why we bring our own Python? Are the reasons still valid after the update to 2.7.3? I just updated main/external_deps.lst to load the tarball from python.org and had almost chosen the windows binary instead of the source tarball. I am now wondering why we don't have a build prerequisite on a pre-installed, standard Python. Thanks, Andre -- Alexandro Colorado OpenOffice.org Español http://es.openoffice.org
Re: Python
On 8/2/12, Alexandro Colorado j...@oooes.org wrote: The issue was written on the UDK site explaining this issue. http://www.openoffice.org/udk/python/python-bridge.html#faq I already have python installed on my system, why does the office ship another python ? Python itself is shipped with OpenOffice.org, because python must have been compiled with the same C++ compiler as the office itself on all platforms that use the gcc compiler (e.g. Linux, BSD, etc.). On most Unix platforms, no python shared libraries are available by default (though some distributions do so). This would have meant, that python UNO components cannot be executed within the office process. Python component developers need a guaranteed minimum platform which they can rely on. Recognition of a python runtime at the installation system would have been an extremely difficult and time consuming task becausemany different python installation schemes exist. Packagers of OpenOffice.org will create their own packages, for example redhat or debian, without Python. The standard distribution must run on low end systems. Can I use system's python installation ? See here. (http://www.openoffice.org/udk/python/python-bridge.html#replacing) Basically is a lack of support, some dev hours could permanently fix this issue. But someone needs to do it. On 8/2/12, Andre Fischer awf@gmail.com wrote: Hi all, Can anybody remind me of why we bring our own Python? Are the reasons still valid after the update to 2.7.3? I just updated main/external_deps.lst to load the tarball from python.org and had almost chosen the windows binary instead of the source tarball. I am now wondering why we don't have a build prerequisite on a pre-installed, standard Python. Thanks, Andre -- Alexandro Colorado OpenOffice.org Español http://es.openoffice.org By the way, I think most distros already make this adjustment using the system python from the openoffice.org-python...deb/rpm. http://rpmfind.net/linux/rpm2html/search.php?query=openoffice.org-pyuno The package just include the libpyuno and objects, but no binary in itself. -- Alexandro Colorado OpenOffice.org Español http://es.openoffice.org
Re: Python
On 02.08.2012 14:48, Alexandro Colorado wrote: On 8/2/12, Alexandro Colorado j...@oooes.org wrote: The issue was written on the UDK site explaining this issue. http://www.openoffice.org/udk/python/python-bridge.html#faq I already have python installed on my system, why does the office ship another python ? Python itself is shipped with OpenOffice.org, because python must have been compiled with the same C++ compiler as the office itself on all platforms that use the gcc compiler (e.g. Linux, BSD, etc.). On most Unix platforms, no python shared libraries are available by default (though some distributions do so). This would have meant, that python UNO components cannot be executed within the office process. Python component developers need a guaranteed minimum platform which they can rely on. Recognition of a python runtime at the installation system would have been an extremely difficult and time consuming task becausemany different python installation schemes exist. Packagers of OpenOffice.org will create their own packages, for example redhat or debian, without Python. The standard distribution must run on low end systems. Can I use system's python installation ? See here. (http://www.openoffice.org/udk/python/python-bridge.html#replacing) Basically is a lack of support, some dev hours could permanently fix this issue. But someone needs to do it. On 8/2/12, Andre Fischer awf@gmail.com wrote: Hi all, Can anybody remind me of why we bring our own Python? Are the reasons still valid after the update to 2.7.3? I just updated main/external_deps.lst to load the tarball from python.org and had almost chosen the windows binary instead of the source tarball. I am now wondering why we don't have a build prerequisite on a pre-installed, standard Python. Thanks, Andre -- Alexandro Colorado OpenOffice.org Español http://es.openoffice.org By the way, I think most distros already make this adjustment using the system python from the openoffice.org-python...deb/rpm. http://rpmfind.net/linux/rpm2html/search.php?query=openoffice.org-pyuno The package just include the libpyuno and objects, but no binary in itself. Thanks for the info. Much appreciated. -Andre
Re: Python
Hello guys; FWIW, the update to version 2.7.3 doesnt really bring a big difference wrt 2.6.1 but I dont think we will be able to update python further in a long while because there are extensions out there that depend on Python2. Adding Python3 compatibility is not difficult, I think, but an interesting alternative, that people can try now, would be to build/ship AOO with PyPy : http://pypy.org/ Cheers, Pedro.
Re: Python and other scripting framework
Am 20.10.2011 17:47, schrieb Alexandro Colorado: Wonder what is the future of the UNO scripting framework since there are many languages with different languages like Python, Beanshell and other scriptings that OOo ships. OOo builds have a full Python 2.6 version and also IDE like Rhino and other applications that are stringly attached to the OpenOffice.org core. Python is not related to the Scripting Framework, it has its own UNO Language Binding. The Scripting Framework adds support for some scripting languages with an interpreter written in Java. Besides that I would expect that the future of the Scripting Framework will be defined by those who will work on it. Until developers show up for that, it most probably will stay as it is. Regards, Mathias
