Creating Python-related Ebuilds - Revision history

Drobbins: /* The old way: python-updater */

2012-04-14T03:04:19Z

‎The old way: python-updater

Drobbins: /* The new way: new python eclass */

2012-04-14T03:03:07Z

‎The new way: new python eclass

Drobbins: /* The old way: python-updater */

2012-04-14T03:02:07Z

‎The old way: python-updater

Drobbins: /* Progress Improvements */

2012-04-14T03:01:15Z

‎Progress Improvements

Drobbins: /* Conceptual Overview */

2012-04-14T02:59:18Z

‎Conceptual Overview

Drobbins: /* Summary */

2012-04-14T02:56:37Z

‎Summary

Drobbins: /* python_abi_depend() with -i and -e */

2012-04-13T21:59:25Z

‎python_abi_depend() with -i and -e

Drobbins at 21:55, 13 April 2012

2012-04-13T21:55:46Z

Drobbins at 21:55, 13 April 2012

2012-04-13T21:55:02Z

Drobbins: moved Progress Overlay Python to Creating Python-related Ebuilds

2012-04-13T21:53:52Z

moved Progress Overlay Python to Creating Python-related Ebuilds

← Older revision		Revision as of 03:04, 14 April 2012
Line 20:		Line 20:

	With the older <tt>python.eclass</tt> in Gentoo (and that used to be in Funtoo Linux,) python modules are built for all installed versions of Python. However, no usable accounting information was stored by Portage so that it could "know" what versions of python the module was built for. This created a problem when new versions of Python are installed, as the new module would not be available for the new python, and Portage would not be aware of what needed to be done to fix this, if anything. This resulted in the creation of a tool called <tt>python-updater</tt> to rebuild all necessary python-related ebuilds so that they reflected the currently-installed versions of Python.		With the older <tt>python.eclass</tt> in Gentoo (and that used to be in Funtoo Linux,) python modules are built for all installed versions of Python. However, no usable accounting information was stored by Portage so that it could "know" what versions of python the module was built for. This created a problem when new versions of Python are installed, as the new module would not be available for the new python, and Portage would not be aware of what needed to be done to fix this, if anything. This resulted in the creation of a tool called <tt>python-updater</tt> to rebuild all necessary python-related ebuilds so that they reflected the currently-installed versions of Python.
		+
		+	Note that python-updater-0.10 and later are aware of the new Python eclass, and will not unnecessarily reinstall any packages which set <tt>PYTHON_MULTIPLE_ABIS</tt> and <tt>EAPI="4-python"</tt>, as manual rebuilding is not necessary.

	'''TODO: add python-updater example'''		'''TODO: add python-updater example'''

@@ Line 25: / Line 25: @@
 === The new way: new python eclass ===
-The new <tt>python.eclass</tt> from Arfrever has a new API that can be used to write python ebuilds. When this API is used, Portage can track and resolve missing builds of python modules internally, so <tt>python-updater</tt> is not needed to be used for these ebuilds. However, until all ebuilds are converted to the new API, <tt>python-updater</tt> will need to be used to update these old-style ebuilds.
+The new <tt>python.eclass</tt> from Arfrever has a new API that can be used to write Python ebuilds. When this API is used, Portage can track and resolve missing builds of Python modules internally, so <tt>python-updater</tt> is not needed to be used for these ebuilds. However, until all ebuilds are converted to the new API, <tt>python-updater</tt> will need to be used to update these old-style ebuilds. Fortunately for us, over 400 Python-related ebuilds have been converted to take advantage of the new eclass, with more added weekly.
-−
-python-updater-0.10 doesn't reinstall any packages which set <tt>PYTHON_MULTIPLE_ABIS</tt> and <tt>EAPI="4-python"</tt>, as manual rebuilding is not necessary.
-−
-'''TODO: document mechanisms, USE, etc. that are used to accomplish this and how it works'''
-−
-{{fancynote|Help us document this page so we can help others convert to the new python API from progress overlay :)}}
 == Setting up progress overlay ==

@@ Line 19: / Line 19: @@
 === The old way: python-updater ===
-With the older <tt>python.eclass</tt> in Gentoo (and that used to be in Funtoo Linux,) python modules are built for all installed versions of Python. However, no usable accounting information is stored by Portage so that it can "know" what versions of python the module was built for. This creates a problem when new versions of python are installed, as the new module will not be available for the new python, and Portage will not be aware of what needs to be done to fix this, if anything. This has resulted in the creation of a tool called <tt>python-updater</tt> to rebuild all necessary python-related ebuilds so that they reflect the currently-installed versions of python.
+With the older <tt>python.eclass</tt> in Gentoo (and that used to be in Funtoo Linux,) python modules are built for all installed versions of Python. However, no usable accounting information was stored by Portage so that it could "know" what versions of python the module was built for. This created a problem when new versions of Python are installed, as the new module would not be available for the new python, and Portage would not be aware of what needed to be done to fix this, if anything. This resulted in the creation of a tool called <tt>python-updater</tt> to rebuild all necessary python-related ebuilds so that they reflected the currently-installed versions of Python.
 '''TODO: add python-updater example'''

@@ Line 14: / Line 14: @@
 == Progress Improvements ==
 === The old way: python-updater ===
-With the older <tt>python.eclass</tt> in Gentoo (and that used to be in Funtoo Linux,) python modules are built for all installed versions of python. However, no usable accounting information is stored by Portage so that it can "know" what versions of python the module was built for. This creates a problem when new versions of python are installed, as the new module will not be available for the new python, and Portage will not be aware of what needs to be done to fix this, if anything. This has resulted in the creation of a tool called <tt>python-updater</tt> to rebuild all necessary python-related ebuilds so that they reflect the currently-installed versions of python.
+With the older <tt>python.eclass</tt> in Gentoo (and that used to be in Funtoo Linux,) python modules are built for all installed versions of Python. However, no usable accounting information is stored by Portage so that it can "know" what versions of python the module was built for. This creates a problem when new versions of python are installed, as the new module will not be available for the new python, and Portage will not be aware of what needs to be done to fix this, if anything. This has resulted in the creation of a tool called <tt>python-updater</tt> to rebuild all necessary python-related ebuilds so that they reflect the currently-installed versions of python.
 '''TODO: add python-updater example'''

← Older revision		Revision as of 02:59, 14 April 2012
Line 10:		Line 10:

	To use <tt>python.eclass</tt>, you first want to investigate how python module building is integrated into any included <tt>Makefile</tt> or build script. Since we want <tt>python.eclass</tt> to build these modules for us, typically the first step is to tweak the <tt>Makefile</tt> or <tt>configure</tt> script to explicitly not build python modules. We will be handling that process using <tt>python.eclass</tt>.		To use <tt>python.eclass</tt>, you first want to investigate how python module building is integrated into any included <tt>Makefile</tt> or build script. Since we want <tt>python.eclass</tt> to build these modules for us, typically the first step is to tweak the <tt>Makefile</tt> or <tt>configure</tt> script to explicitly not build python modules. We will be handling that process using <tt>python.eclass</tt>.
		+
		+	Another option, for those Python packages with a <tt>setup.py</tt> in the root source directory, is to use the <tt>distutils</tt> eclass. In this case, you generally do not need custom <tt>src_compile</tt> or <tt>src_install</tt> stages, as the eclass takes care of everything for you. However, you will still need to set the proper environment variables described below, as they are needed by <tt>python.eclass</tt> which is used by <tt>distutils.eclass</tt>. You will also want to set dependencies in <tt>DEPEND</tt> and <tt>RDEPEND</tt> as described in this article.

	== Progress Improvements ==		== Progress Improvements ==

@@ Line 1: / Line 1: @@
 == Summary ==
-Funtoo Linux incorporates Progress Overlay into the main Portage tree, which currently contains 400+ udpated Python-related packages that implement next-generation Python support for ebuilds.
+Funtoo Linux incorporates Progress Overlay into the main Portage tree, which currently contains 400+ updated Python-related packages that implement next-generation Python support for ebuilds.
 == Building Python Modules with Portage ==

← Older revision		Revision as of 21:59, 13 April 2012
Line 145:		Line 145:

	On an unrelated note, <tt>nova</tt> is configured with <tt>PYTHON_MULTIPLE_ABIS=1</tt> because it installs a ton of Python modules into <tt>site-packages</tt>.		On an unrelated note, <tt>nova</tt> is configured with <tt>PYTHON_MULTIPLE_ABIS=1</tt> because it installs a ton of Python modules into <tt>site-packages</tt>.
		+
		+	==== common python_abi_depend() dependencies ====
		+
		+	This section is dedicated to providing examples on how to handle common dependencies that are found in Python-related packages:
		+
		+	===== argparse =====
		+
		+	If the Python package's <tt>setup.py</tt> contains something like this:
		+
		+	<pre>
		+	if sys.version_info < (2, 7):
		+	requirements.append('argparse')
		+	</pre>
		+
		+	...then use the following dependency syntax:
		+
		+	<pre>
		+	(R)DEPEND="$(python_abi_depend virtual/python-argparse)"
		+	</pre>

	==== python_abi_depend() with -i and -e ====		==== python_abi_depend() with -i and -e ====

← Older revision		Revision as of 21:55, 13 April 2012
Line 183:		Line 183:

	[[Category:Featured]]		[[Category:Featured]]
		+	[[Category:Portage]]
		+	[[Category:Python]]
		+	[[Category:OpenStack]]