This eclass is needed to add extensions/modules to the ptyhon2.1 series. This eclass makes it possible to take a current .ebuild in portage and edit it to inherit distutils21.
Created attachment 7338 [details] portage/eclass/distutils21.eclass
Please don't assign bugs to me at this time, I'm an inactive developer. Thanks
What would be the benefit of this change?
Bart, mysql-python, egenix-mx-base, & PyXML add extensions to virtual/python, which happens to belong to the python2.2 brance on my box. [code] # emerge egenix-mx-base ... running build_ext building 'mx.DateTime.mxDateTime.mxDateTime' extension creating build/temp.linux-i686-2.2 creating build/temp.linux-i686-2.2/mx creating build/temp.linux-i686-2.2/mx/DateTime creating build/temp.linux-i686-2.2/mx/DateTime/mxDateTime creating build/temp.linux-i686-2.2/mx/DateTime/mxDateTime/mxDateTime gcc -DNDEBUG -fPIC -Imx/DateTime/mxDateTime -I/usr/include/python2.2 -c mx/DateTime/mxDateTime/mxDateTime.c -o build/temp.linux-i686-2.2/mx/DateTime/mxDateTime/mxDateTime/mxDateTime.o -march=athlon-tbird -O3 -pipe ... byte-compiling /var/tmp/portage/egenix-mx-base-2.0.3/image//usr/lib/python2.2/site-packages/mx/TextTools/Examples/__init__.py to __init__.pyo byte-compiling /var/tmp/portage/egenix-mx-base-2.0.3/image//usr/lib/python2.2/site-packages/mx/TextTools/Examples/altRTF.py to altRTF.pyo ... >>> Merging dev-python/egenix-mx-base-2.0.3 to / --- /usr/ --- /usr/lib/ --- /usr/lib/python2.2/ --- /usr/lib/python2.2/site-packages/ >>> /usr/lib/python2.2/site-packages/mx/ >>> /usr/lib/python2.2/site-packages/mx/Log.py >>> /usr/lib/python2.2/site-packages/mx/NewBuiltins.py >>> /usr/lib/python2.2/site-packages/mx/__init__.py >>> /usr/lib/python2.2/site-packages/mx/DateTime/ [/code] So this is an ebuild only for python2.2, and that is where the extensions are placed. The problem I was having is that Zope bug #13751 is required to use python-2.1.3. Zope has 3rd-party Products, some of which require extensions to python. Since the Zope products run within Zope, which is running over python2.1, the extensions need to be in the python2.1/site-packages area. egenix-mx-base-py21-2.04 (bug #14004) helps solves this problem (same python extension package version, but different python versions(using SLOTs)). [code] kutsuya zope # emerge egenix-mx-base-py21 Calculating dependencies ...done! >>> emerge (1 of 1) dev-python/egenix-mx-base-py21-2.0.4 to / >>> md5 ;-) egenix-mx-base-2.0.4.tar.gz ... building extension "mx.DateTime.mxDateTime.mxDateTime" (required) building 'mx.DateTime.mxDateTime.mxDateTime' extension creating build creating build/temp.linux-i686-2.1 creating build/temp.linux-i686-2.1/mx creating build/temp.linux-i686-2.1/mx/DateTime creating build/temp.linux-i686-2.1/mx/DateTime/mxDateTime creating build/temp.linux-i686-2.1/mx/DateTime/mxDateTime/mxDateTime gcc -march=athlon-tbird -O3 -pipe -fPIC -Imx/DateTime/mxDateTime -I/usr/include/python2.1 -I/usr/include -c mx/DateTime/mxDateTime/mxDateTime.c -o build/temp.linux-i686-2.1/mx/DateTime/mxDateTime/mxDateTime/mxDateTime.o -march=athlon-tbird -O3 -pipe ... byte-compiling /var/tmp/portage/egenix-mx-base-py21-2.0.4/image/usr/lib/python2.1/site-packages/mx/DateTime/mxDateTime/testcmp.py to testcmp.pyc byte-compiling /var/tmp/portage/egenix-mx-base-py21-2.0.4/image/usr/lib/python2.1/site-packages/mx/DateTime/mxDateTime/testnow.py to testnow.pyc ... >>> Merging dev-python/egenix-mx-base-py21-2.0.4 to / --- /usr/ --- /usr/lib/ --- /usr/lib/python2.1/ --- /usr/lib/python2.1/site-packages/ --- /usr/lib/python2.1/site-packages/mx/ --- /usr/lib/python2.1/site-packages/mx/DateTime/ --- /usr/lib/python2.1/site-packages/mx/DateTime/mxDateTime/ [/code] Is there another way to deal with this problem? Which is to add newer extentions/modules to certain/all emerged SLOTted packages. Thanks for any help you can provide. :)
Bart, Hope you don't mind me reassigning these bugs to myself. I'll probably be asking questions later.
Do not add this as-is please.
Created attachment 8402 [details] distutils.eclass Here is a modified distutils.eclass. Example of use: bug #14004. Is there some way I can expedite adding this to cvs? Thanks.
I think this last proposed change is more appropriate I would be slightly more in favor of setting $python to the correct bynary in your loop since it keeps the code more readable like: <code>if [ $(use py21) ] ; then newdepend "virtual/python-2.1" python="python-2.1" else newdepend "virutal/python" python="python" fi distutils_src_compile() { ${python} setup.py build || die "compilation failed" }</code> This looks good so after you (re)test it submit it. Bart
Created attachment 8545 [details] eclass/distutils.eclass Good call on the python variable. :"> After thinking about it some more, I don't see a need for a USE flag py21. It seems best to just set a varible like PYTHON_SLOT_VERSION=2.1 in the ebuilds that want to use virtual/python-2.1. This seems to cause the least amount of problems for developers that are not concerned about adding extentions to older slots. What do you think?
Looks like I left a debugging echo in eclass, that will be removed later of course.
Comment on attachment 8545 [details] eclass/distutils.eclass ># Copyright 1999-2003 Gentoo Technologies, Inc. ># Distributed under the terms of the GNU General Public License v2 ># $Header: $ ># ># Author: Jon Nelson <jnelson@gentoo.org> ># ># The distutils eclass is designed to allow easier installation of ># distutils-based python modules, and their incorporation into ># the Gentoo Linux system. > >ECLASS=distutils >INHERITED="$INHERITED $ECLASS" > >EXPORT_FUNCTIONS src_compile src_install > >if [ "${PYTHON_SLOT_VERSION}" = 2.1 ] ; then > newdepend "virtual/python-2.1" > python="python2.1" >else > newdepend "virutal/python" > python="python" >fi > >distutils_src_compile() { > ${python} setup.py build || die "compilation failed" >} > >distutils_src_install() { > ${python} setup.py install --root=${D} || die > > dodoc CHANGELOG COPYRIGHT KNOWN_BUGS MAINTAINERS > dodoc CONTRIBUTORS LICENSE COPYING* > dodoc Change* MANIFEST* README* ${mydoc} >}
Something similar now in Portage tree.
