* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/Python/python-r1: dev-guide.xml
@ 2012-11-10 8:26 Michal Gorny (mgorny)
0 siblings, 0 replies; 19+ messages in thread
From: Michal Gorny (mgorny) @ 2012-11-10 8:26 UTC (permalink / raw
To: gentoo-commits
mgorny 12/11/10 08:26:20
Added: dev-guide.xml
Log:
The initial version of python-r1 Developer's Guide.
Revision Changes Path
1.1 xml/htdocs/proj/en/Python/python-r1/dev-guide.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.1&content-type=text/plain
Index: dev-guide.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.1 2012/11/10 08:26:20 mgorny Exp $ -->
<guide lang="en">
<title>python-r1 Developer's Guide</title>
<author title="Author">
<mail link="mgorny@gentoo.org">Michał Górny</mail>
</author>
<author title="Editor">
<mail link="idella4@gentoo.org">Ian Delaney</mail>
</author>
<abstract>
This guide provides a basic insight to writing ebuilds using
the python-r1 and distutils-r1 eclasses.
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/3.0/ -->
<license version="3.0"/>
<version>1</version>
<date>2012-11-04</date>
<chapter id="Introductory_info">
<title>Introductory information</title>
<section id="ii_When_to_use">
<title>When to use?</title>
<body>
<p>
The new Python eclasses, python-r1 and distutils-r1, are still
considered ‘testing grade’. Although they can be used
in the tree, they must not be used on stable packages
or packages which will need to be stabilized soon. For that
reason, it is usually a good idea to revbump the package when
converting.
</p>
<p>
It should be noted that the -r1 eclasses are not a drop-in
replacement for python.eclass. They differ in design and goals.
At the moment, they also lack some of the functionality.
The most important gap is lack of support for packages
not supporting installation for multiple Python implementations.
</p>
</body>
</section>
<section id="ii_Purpose_of_the_eclasses">
<title>Purpose of the eclasses</title>
<body>
<p>
The python-r1 suite consists of the python-r1 and distutils-r1
eclasses.
</p>
<p>
The python-r1 eclass is the fundamental eclass for all Python
packages. It covers the general aspects, helping ebuild
developers to handle building packages for multiple Python
implementations and write proper dependency strings. However,
it does not enforce any dependencies itself nor export phase
functions.
</p>
<p>
The distutils-r1 eclass extends python-r1 with a simple to use
framework to build and install packages using the standard
Python distutils build system. It follows the common practices
for build system eclasses, exporting phase functions which
handle applying patches, building and installing.
</p>
<p>
In the vast majority of cases, the distutils-r1 will the best
choice for your ebuild. The python-r1 should be mostly used
in packages which do not use the distutils build system or use
it in a non-standard way.
</p>
<note>
Please note that the distutils-r1 eclass inherits python-r1
implicitly. There is therefore no need to ever inherit both.
</note>
</body>
</section>
</chapter>
<chapter id="The_fundamentals_of_python_r1_eclass">
<title>The fundamentals of python-r1 eclass</title>
<section id="pr1_Listing_supported_Python_implementations">
<title>Listing supported Python implementations</title>
<body>
<p>
The first and most important task in writing ebuilds both
for python-r1 and distutils-r1 is to specify the list of Python
implementations supported by the ebuild.
</p>
<p>
The list of supported implementations is specified using
the <c>PYTHON_COMPAT</c> variable. It is an obligatory array
which has to be declared before the <c>inherit</c> command.
It should list <e>all</e> supported implementations using
the following naming scheme:
</p>
<ol>
<li><c>pythonX_Y</c> for CPython X.Y;</li>
<li><c>pypyX_Y</c> for PyPy X.Y;</li>
<li><c>jythonX_Y</c> for Jython X.Y.</li>
</ol>
<p>
<c>PYTHON_COMPAT</c> should be treated with respect similar
to the <c>KEYWORDS</c> variable. No implementation should
be added there without prior testing, and all package
dependencies must support that implementation.
</p>
<p>
The <c>PYTHON_COMPAT</c> variable can be considered
a replacement for python.eclass' <c>PYTHON_DEPEND</c>
and <c>RESTRICT_PYTHON_ABIS</c> variables.
</p>
<pre caption="Examples of PYTHON_COMPAT">
<comment># Any version of CPython 2.</comment>
<ident>PYTHON_COMPAT</ident>=( python2_5 python2_6 python2_7 )
<comment># Python 2 or 3, using brace expansion.</comment>
<ident>PYTHON_COMPAT</ident>=( python{2_5,2_6,2_7,3_1,3_2,3_3} )
<comment># Python 2.6+ and compliant implementations.</comment>
<ident>PYTHON_COMPAT</ident>=( python{2_6,2_7} pypy{1_8,1_9} )
<comment># inherit goes below PYTHON_COMPAT</comment>
<keyword>inherit</keyword> python-r1
</pre>
</body>
</section>
<section id="pr1_Depending_on_Python">
<title>Depending on Python</title>
<body>
<note>
Please note that this section applies to the sole use
of python-r1 eclass only. The distutils-r1 eclass
unconditionally adds Python dependency.
</note>
<p>
In order to efficiently handle various kinds of package
dependencies on Python, the python-r1 eclass does not set
the ebuild dependencies directly. Instead, it prepares
the proper dependency string and stores it in a variable named
<c>PYTHON_DEPS</c>.
</p>
<p>
The <c>PYTHON_DEPS</c> variable is unconditionally set
by the eclass to a list of proper USE-conditional dependencies
on enabled Python implementations. It also holds any additional
dependencies necessary — most notably, a dependency
on <c>dev-python/python-exec</c>.
</p>
<p>
The ebuild should reference the <c>PYTHON_DEPS</c> variable
in <c>RDEPEND</c> and/or <c>DEPEND</c> as necessary. It may need
to put those dependencies into an appropriate USE-conditional
block.
</p>
<pre caption="Example uses of PYTHON_DEPS">
<comment># Unconditional Python run-time + build-time dependency.</comment>
<ident>RDEPEND</ident>=${PYTHON_DEPS}
<ident>DEPEND</ident>=${RDEPEND}
<comment># Unconditional Python build-time dependency.</comment>
<ident>DEPEND</ident>=${PYTHON_DEPS}
<comment># USE-conditional Python run-time dependency.</comment>
<ident>RDEPEND</ident>="<const>python?</const> ( ${PYTHON_DEPS} )"
</pre>
</body>
</section>
<section id="pr1_Depending_on_other_Python_packages">
<title>Depending on other Python packages</title>
<body>
<p>
There are currently two kinds of Python packages in the tree;
one which explicitly specify enabled Python implementations via
<c>PYTHON_TARGETS</c>, and consists of ebuilds using python-r1
and python-distutils-ng eclasses, the other which lacks such
a support. These are packages using the ‘original’
python.eclass.
</p>
<p>
When a dependency against a package supporting
<c>PYTHON_TARGETS</c> is to be expressed, a USE dependency
should be specified to ensure that the dependencies
are installed for all required Python implementations.
The eclass provides the necessary dependency string fragment
in <c>PYTHON_USEDEP</c> variable.
</p>
<p>
The <c>PYTHON_USEDEP</c> variable is set unconditionally
by the eclass. It contains a bare compact USE dependency string,
enforcing a requirement on all selected Python implementations.
</p>
<p>
Depending on packages not supporting <c>PYTHON_TARGETS</c>
is discouraged. Whenever possible, please consider migrating
the dependant package instead. Such a dependency is unable
to enforce the fore-mentioned requirement, therefore making
the user vulnerable to unclear nuisance failures.
The dependencies on packages of that kind are expressed using
the regular (simple) dependency syntax.
</p>
<pre caption="Example use of PYTHON_USEDEP">
<comment># Simple dependency on a python-r1 package.</comment>
<ident>RDEPEND</ident>="<const>dev-python/setuptools</const>[${PYTHON_USEDEP}]"
<comment># Dependency with additional USE flags requested.</comment>
<ident>RDEPEND</ident>="<const>dev-python/lxml</const>[threads,${PYTHON_USEDEP}]"
<comment># Dependency on a package using python.eclass.</comment>
<ident>RDEPEND</ident>="<const>dev-python/wxpython:2.8</const>"
</pre>
</body>
</section>
<section id="pr1_Requesting_optional_Python_features">
<title>Requesting optional Python features (modules)</title>
<body>
<p>
Sometimes it is necessary to depend on a feature or module which
belongs to the Python implementation itself but is not always
available. The availability can depend both on Python version
and USE flags. These features can be divided into two types;
those having replacement modules and those lacking them.
</p>
<p>
If a particular module has a replacement package, the correct
way to require it is to depend on the respective virtual
package. For example, a script using the <c>argparse</c> module
should depend on <c>virtual/python-argparse</c>. The virtual
will either enforce a particular USE constraints or pull in
the replacement package as necessary.
</p>
<p>
If a particular module or feature is provided by the Python
implementation only, and is conditional upon the setting
of a USE flag, <c>PYTHON_REQ_USE</c> should be used instead.
</p>
<p>
The <c>PYTHON_REQ_USE</c> variable is an optional variable which
can be used to enforce a set of USE flag requirements
upon the Python implementation. It takes a bare USE dependency
string and appends it to the dependency on <e>every</e> Python
implementation supported. Sometimes it may be necessary to use
EAPI 4 USE defaults to handle cases when a particular flag
is enabled unconditionally in some of the supported
implementations.
</p>
<p>
The <c>PYTHON_REQ_USE</c> variable can be considered
a replacement for python.eclass' <c>PYTHON_USE_WITH</c>
variable.
</p>
<pre caption="Example uses of virtuals and PYTHON_REQ_USE">
<comment># Run-time dependency on argparse module (through virtuals).</comment>
<ident>RDEPEND</ident>="virtual/python-argparse[<var>${PYTHON_USEDEP}</var>]"
<comment># Simple dependency on ncurses support.</comment>
<ident>PYTHON_REQ_USE</ident>="ncurses"
<comment># Dependency on bzip2 support (conditional in PyPy, always enabled in CPython).</comment>
<ident>PYTHON_REQ_USE</ident>="bzip2(+)"
</pre>
</body>
</section>
<section id="pr1_Obtaining_Python_implementation_information">
<title>Obtaining Python implementation information</title>
<body>
<p>
Sometimes it is necessary to obtain information specific
to a particular Python implementations, in particular
interpreter-specific paths. The python-r1 eclass provides
the following means of obtaining that information:
</p>
<ol>
<li><c>python_export</c> function,</li>
<li><c>python_export_best</c> function,</li>
<li>getter functions.</li>
</ol>
<p>
The <c>python_export</c> and <c>python_export_best</c> functions
take an optional list of variable names and export
the requested variables. When no variable names are passed,
the default variable list is used.
</p>
<p>
The <c>python_export</c> can additionally take a Python
implementation as a first argument, either in the form of a USE
flag or an <c>EPYTHON</c> value. If such a form is used,
the values specific to the passed implementation are exported.
Otherwise, the currently used implementation (the <c>EPYTHON</c>
environment variable) is used.
</p>
<p>
The <c>python_export_best</c> exports variables for the ‘best’
of the currently enabled implementations; that is, the newest
interpreter version from the most preferred group. These groups
are, in order of preference:
</p>
<ol>
<li>CPython 2,</li>
<li>CPython 3,</li>
<li>PyPy,</li>
<li>Jython.</li>
</ol>
<p>
The getter functions print the value of a specific property
to standard output. The output can be captured using bash
command substitution. These functions take an optional parameter
specifying the requested Python implementation.
If not specified, the current one will be used.
</p>
<p>
The following table lists all the available variables, along
with the respective getter functions:
</p>
<table>
<tr>
<th>Variable name</th>
<th>Getter function</th>
<th>Default?</th>
<th>Description</th>
</tr>
<tr>
<ti><c>EPYTHON</c></ti>
<ti><c>python_get_EPYTHON</c></ti>
<ti>yes</ti>
<ti>
The Python implementation name (Gentoo-specific).
</ti>
</tr>
<tr>
<ti><c>PYTHON</c></ti>
<ti><c>python_get_PYTHON</c></ti>
<ti>yes</ti>
<ti>
Absolute path to the Python interpreter.
</ti>
</tr>
<tr>
<ti><c>PYTHON_SITEDIR</c></ti>
<ti><c>python_get_sitedir</c></ti>
<ti>no</ti>
<ti>
Path to the Python site-packages directory (where modules
should be installed).
</ti>
</tr>
</table>
</body>
</section>
</chapter>
<chapter id="The_distutils_r1_eclass">
<title>The distutils-r1 eclass</title>
<section id="dr1_Tasks_performed_by_distutils_r1">
<title>Tasks performed by distutils-r1</title>
<body>
<p>
The distutils-r1 exports a set of phase functions performing
common tasks related to building and installing the package.
In many cases, those tasks will suffice for a typical Python
package.
</p>
<p>
The tasks performed by distutils-r1 are (in execution order):
</p>
<ol>
<li>applying patches listed in the <c>PATCHES</c> array;</li>
<li>applying user patches (the <c>epatch_user</c> function);</li>
<li>building and installing the package using <c>setup.py</c>;</li>
<li>ensuring that Python scripts are installed in multiple
variants according to the enabled Python implementations;</li>
<li>installing additional documentation (using <c>DOCS</c>
and <c>HTML_DOCS</c> arrays).</li>
</ol>
<pre caption="Example on enabling patching and additional
documentation">
<keyword>PATCHES</keyword>=(
<comment># bug #nnnnnn, a random error with something.</comment>
"${FILESDIR}"/${P}-foo.patch
<comment># bug #nnnnnn, some other error.</comment>
"${FILESDIR}"/${P}-bar.patch
)
<keyword>DOCS</keyword>=( README.md )
<keyword>HTML_DOCS</keyword>=( doc/html/ )
</pre>
<note>
The listed variables can be either set in the global scope
or in the scope of the respective phase function.
The <c>PATCHES</c> variable can be set in <c>src_prepare()</c>
or <c>python_prepare_all()</c> instead, while <c>DOCS</c>
and <c>HTML_DOCS</c> can be set in <c>src_install()</c>
or <c>python_install_all()</c>.
</note>
</body>
</section>
<section id="dr1_The_partial_phase_functions">
<title>The ‘partial’ phase functions</title>
<body>
<p>
The distutils-r1 eclass utilises a mechanism inspired by phase
functions to make writing ebuilds relatively easy. For each
phase function handled by distutils-r1, namely all <c>src_*</c>
phases, two ‘partial’ phases are used; the per-implementation
sub-phase and the common sub-phase.
</p>
<p>
The sub-phase functions are named for the corresponding
<c>src_*</c> phase but with the <c>src</c> prefix replaced
by <c>python</c>. For example, the compilation sub-phase
function has to be named <c>python_compile</c>. These functions
are called once for each enabled Python implementation
and perform tasks specific to it. They are called
with the standard implementation information variables exported
(<c>EPYTHON</c>, <c>PYTHON</c>…).
</p>
<p>
An additional <c>_all</c> suffix is appended to the common
sub-phase functions. For example, the installation sub-phase
function is subsequently named <c>python_install_all</c>. These
functions are called only once in the main source directory
and they perform tasks common to all enabled implementations.
</p>
<p>
The distutils-r1 eclass provides default functions for all
per-implementation sub-phases and for <c>python_prepare_all</c>
and <c>python_install_all</c>. If you are replacing any
of those phase functions, you ought call the respective
<c>distutils-r1_*</c> phase function in it.
</p>
<pre caption="Example of defining sub-phase functions">
<keyword>python_compile_all()</keyword> {
if use doc; then
python_export_best
"${PYTHON}" setup.py doc || die
fi
}
<keyword>python_test()</keyword> {
"${PYTHON}" setup.py test || die
}
<keyword>python_install_all()</keyword> {
use doc && local HTML_DOCS=( doc/* )
<keyword>distutils-r1_python_install_all</keyword>
}</pre>
</body>
</section>
<section id="dr1_Out_of_source_and_in_source_builds">
<title>Out-of-source and in-source builds</title>
<body>
<p>
There are two modes of building packages with distutils-r1;
‘out-of-source builds’ (the default) and ‘in-source builds’.
An out-of-source build uses a common source directory, reads
files from that directory but locates the built files
in a separate directory. An in-source build locates both
the source and output files in the same directory.
</p>
<p>
When an out-of-source build is used, the phase functions are run
in the <c>${S}</c> directory. The build directory used
for the particular implementation is stored
in the <c>BUILD_DIR</c> variable, all calls to <c>setup.py</c>
pass additional <c>build --build-base…</c> parameters pointing
to it and the <path>lib</path> subdirectory of the build
directory is added to <c>PYTHONPATH</c>. As a side effect,
the package is built on the first <c>setup.py</c> invocation.
</p>
<p>
The in-source builds are implemented for more problematic
packages where out-of-source builds may not work due to bugs
in the build system. They are enabled either explicitly
when the <c>DISTUTILS_IN_SOURCE_BUILD</c> variable is set
(to any value) or implicitly when the <c>python_prepare</c>
(per-implementation one) sub-phase is declared.
</p>
<p>
When in-source builds are enabled, the default
<c>python_prepare_all</c> first creates a copy of all
the sources in the <c>BUILD_DIR</c> for each implementation.
Common sub-phase functions are still executed in the source
directory but per-implementation sub-phases are executed
in the build directory for each implementation. There is
no explicit linking between the source copies, therefore
the build system is allowed to modify them freely.
</p>
</body>
</section>
</chapter>
<!-- vim:se tw=72 ts=2 sts=2 sw=2 :-->
</guide>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/Python/python-r1: dev-guide.xml
@ 2012-11-24 21:34 Michal Gorny (mgorny)
0 siblings, 0 replies; 19+ messages in thread
From: Michal Gorny (mgorny) @ 2012-11-24 21:34 UTC (permalink / raw
To: gentoo-commits
mgorny 12/11/24 21:34:34
Modified: dev-guide.xml
Log:
Update for the new eclasses, clean up a bit.
Revision Changes Path
1.2 xml/htdocs/proj/en/Python/python-r1/dev-guide.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.2&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.2&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?r1=1.1&r2=1.2
Index: dev-guide.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- dev-guide.xml 10 Nov 2012 08:26:20 -0000 1.1
+++ dev-guide.xml 24 Nov 2012 21:34:34 -0000 1.2
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.1 2012/11/10 08:26:20 mgorny Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.2 2012/11/24 21:34:34 mgorny Exp $ -->
<guide lang="en">
<title>python-r1 Developer's Guide</title>
@@ -23,8 +23,8 @@
<!-- See http://creativecommons.org/licenses/by-sa/3.0/ -->
<license version="3.0"/>
-<version>1</version>
-<date>2012-11-04</date>
+<version>2</version>
+<date>2012-11-24</date>
<chapter id="Introductory_info">
<title>Introductory information</title>
@@ -52,42 +52,151 @@
</body>
</section>
+ <section id="ii_Types_of_Python_packages">
+ <title>Types of Python packages</title>
+
+ <body>
+ <p>
+ The Python packages in Gentoo, that is packages either
+ installing Python modules or embedding the Python interpreter,
+ can be divided into three main groups:
+ </p>
+
+ <ol>
+ <li>
+ packages which are capable of being installed for multiple
+ selected Python implementations;
+ </li>
+
+ <li>
+ packages which are capable of being installed for a single
+ chosen Python implementation only;
+ </li>
+
+ <li>
+ packages being installed independently of Python
+ implementations.
+ </li>
+ </ol>
+
+ <p>
+ The first group is the most common one and comprises most
+ of the packages installing Python modules and/or scripts.
+ The installed files are either directed
+ to implementation-specific directories or renamed in order
+ to allow installing multiple copies, one for each enabled Python
+ implementation. This way, the packages can cleanly guarantee
+ that the particular packages can be used with any implementation
+ installed.
+ </p>
+
+ <p>
+ The second group consists of most of the packages embedding
+ the Python interpreter or installing Python bindings as a part
+ of a more general build system. The installed files can
+ be installed only once and only for one chosen Python
+ implementation. The package can't be used by any other
+ installed Python implementation.
+ </p>
+
+ <p>
+ The third group comprises mostly very specific packages which
+ do not fit the regular Python package model. This includes
+ packages which are installed externally and can be used
+ by multiple Python implementations,
+ such as <c>sys-apps/portage</c>.
+ </p>
+ </body>
+ </section>
+
<section id="ii_Purpose_of_the_eclasses">
<title>Purpose of the eclasses</title>
<body>
<p>
- The python-r1 suite consists of the python-r1 and distutils-r1
- eclasses.
+ The python-r1 suite consists of four eclasses:
</p>
+ <ol>
+ <li><c>python-utils-r1</c>,</li>
+ <li><c>python-r1</c>,</li>
+ <li><c>distutils-r1</c>,</li>
+ <li><c>python-single-r1</c>.</li>
+ </ol>
+
<p>
- The python-r1 eclass is the fundamental eclass for all Python
- packages. It covers the general aspects, helping ebuild
- developers to handle building packages for multiple Python
- implementations and write proper dependency strings. However,
- it does not enforce any dependencies itself nor export phase
+ The <c>python-utils-r1</c> eclass is the most fundamental eclass
+ in the suite. It does not export any phase functions nor set
+ any metadata. It does not require the package to fit
+ any specific model.
+ </p>
+
+ <p>
+ The <c>python-r1</c> eclass is the second fundamental eclass.
+ It extends the former eclass with the metadata and variables
+ suited for packages supporting multiple Python implementations:
+ the implementation choice flags, dependency strings. It does
+ not, however, enforce any dependencies directly nor export phase
functions.
</p>
<p>
- The distutils-r1 eclass extends python-r1 with a simple to use
- framework to build and install packages using the standard
- Python distutils build system. It follows the common practices
- for build system eclasses, exporting phase functions which
- handle applying patches, building and installing.
+ The <c>distutils-r1</c> eclass extends python-r1 with a set
+ of basic phase functions to build and install packages using
+ the distutils build system of the inbuilt Python module
+ <c>distutils</c>. It follows the common practices for build
+ system eclasses, including patching and installing
+ documentation.
+ </p>
+
+ <p>
+ The <c>python-single-r1</c> eclass is an alternative
+ to <c>python-r1</c> for packages which do not support being
+ installed for multiple Python implementations. It exports
+ similar metadata and variables, and a <c>pkg_setup</c> phase
+ function handling the target implementation choice.
</p>
<p>
- In the vast majority of cases, the distutils-r1 will the best
- choice for your ebuild. The python-r1 should be mostly used
- in packages which do not use the distutils build system or use
- it in a non-standard way.
+ The choice of eclass for your package could follow the following
+ algorithm:
</p>
+ <ol>
+ <li>
+ if the package supports being installed for multiple Python
+ implementations, the Python part of it is unconditional
+ and uses the distutils build system (or one very similar),
+ use the <c>distutils-r1</c> eclass;
+ </li>
+
+ <li>
+ if the package supports being installed for multiple Python
+ implementations separately and installs Python modules,
+ scripts or embeds Python, use <c>python-r1</c>;
+ </li>
+
+ <li>
+ if the package can be installed for a single Python
+ implementation only and installs Python modules, scripts
+ or embeds Python, use <c>python-single-r1</c>;
+ </li>
+
+ <li>
+ if the package has a specific or loose connection to Python,
+ installs Python modules for multiple implementations
+ in a common location, or has any other special needs,
+ consider using <c>python-utils-r1</c> (although you may
+ not need any eclass at all).
+ </li>
+ </ol>
+
<note>
- Please note that the distutils-r1 eclass inherits python-r1
- implicitly. There is therefore no need to ever inherit both.
+ Please note that the <c>distutils-r1</c>
+ and <c>python-single-r1</c> eclasses inherit <c>python-r1</c>
+ implicitly, and <c>python-r1</c> inherits
+ <c>python-utils-r1</c>. There is therefore no need to ever
+ inherit more than one eclass from the suite.
</note>
</body>
</section>
@@ -96,6 +205,18 @@
<chapter id="The_fundamentals_of_python_r1_eclass">
<title>The fundamentals of python-r1 eclass</title>
+ <section id="pr1_General_notes">
+ <title>General notes</title>
+
+ <body>
+ <note>
+ The variables listed in this section apply to ebuilds using
+ <c>python-single-r1</c> and <c>distutils-r1</c> eclasses as well,
+ through the rules of implicit inheritance.
+ </note>
+ </body>
+ </section>
+
<section id="pr1_Listing_supported_Python_implementations">
<title>Listing supported Python implementations</title>
@@ -107,11 +228,10 @@
</p>
<p>
- The list of supported implementations is specified using
- the <c>PYTHON_COMPAT</c> variable. It is an obligatory array
- which has to be declared before the <c>inherit</c> command.
- It should list <e>all</e> supported implementations using
- the following naming scheme:
+ This list is specified using the <c>PYTHON_COMPAT</c> variable.
+ It is an obligatory array which has to be declared before
+ the <c>inherit</c> command. It should list <e>all</e> supported
+ implementations using the following naming scheme:
</p>
<ol>
@@ -155,8 +275,9 @@
<body>
<note>
Please note that this section applies to the sole use
- of python-r1 eclass only. The distutils-r1 eclass
- unconditionally adds Python dependency.
+ of <c>python-r1</c> or <c>python-single-r1</c> only.
+ The <c>distutils-r1</c> eclass unconditionally adds this
+ dependency.
</note>
<p>
@@ -303,103 +424,6 @@
</pre>
</body>
</section>
-
- <section id="pr1_Obtaining_Python_implementation_information">
- <title>Obtaining Python implementation information</title>
-
- <body>
- <p>
- Sometimes it is necessary to obtain information specific
- to a particular Python implementations, in particular
- interpreter-specific paths. The python-r1 eclass provides
- the following means of obtaining that information:
- </p>
-
- <ol>
- <li><c>python_export</c> function,</li>
- <li><c>python_export_best</c> function,</li>
- <li>getter functions.</li>
- </ol>
-
- <p>
- The <c>python_export</c> and <c>python_export_best</c> functions
- take an optional list of variable names and export
- the requested variables. When no variable names are passed,
- the default variable list is used.
- </p>
-
- <p>
- The <c>python_export</c> can additionally take a Python
- implementation as a first argument, either in the form of a USE
- flag or an <c>EPYTHON</c> value. If such a form is used,
- the values specific to the passed implementation are exported.
- Otherwise, the currently used implementation (the <c>EPYTHON</c>
- environment variable) is used.
- </p>
-
- <p>
- The <c>python_export_best</c> exports variables for the ‘best’
- of the currently enabled implementations; that is, the newest
- interpreter version from the most preferred group. These groups
- are, in order of preference:
- </p>
-
- <ol>
- <li>CPython 2,</li>
- <li>CPython 3,</li>
- <li>PyPy,</li>
- <li>Jython.</li>
- </ol>
-
- <p>
- The getter functions print the value of a specific property
- to standard output. The output can be captured using bash
- command substitution. These functions take an optional parameter
- specifying the requested Python implementation.
- If not specified, the current one will be used.
- </p>
-
- <p>
- The following table lists all the available variables, along
- with the respective getter functions:
- </p>
-
- <table>
- <tr>
- <th>Variable name</th>
- <th>Getter function</th>
- <th>Default?</th>
- <th>Description</th>
- </tr>
-
- <tr>
- <ti><c>EPYTHON</c></ti>
- <ti><c>python_get_EPYTHON</c></ti>
- <ti>yes</ti>
- <ti>
- The Python implementation name (Gentoo-specific).
- </ti>
- </tr>
- <tr>
- <ti><c>PYTHON</c></ti>
- <ti><c>python_get_PYTHON</c></ti>
- <ti>yes</ti>
- <ti>
- Absolute path to the Python interpreter.
- </ti>
- </tr>
- <tr>
- <ti><c>PYTHON_SITEDIR</c></ti>
- <ti><c>python_get_sitedir</c></ti>
- <ti>no</ti>
- <ti>
- Path to the Python site-packages directory (where modules
- should be installed).
- </ti>
- </tr>
- </table>
- </body>
- </section>
</chapter>
<chapter id="The_distutils_r1_eclass">
@@ -462,36 +486,38 @@
<p>
The distutils-r1 eclass utilises a mechanism inspired by phase
functions to make writing ebuilds relatively easy. For each
- phase function handled by distutils-r1, namely all <c>src_*</c>
- phases, two ‘partial’ phases are used; the per-implementation
- sub-phase and the common sub-phase.
+ of the <c>src_*</c> phases, two ‘partial’ phases are used;
+ the implementation-specific sub-phase
+ and the implementation-common sub-phase.
</p>
<p>
- The sub-phase functions are named for the corresponding
- <c>src_*</c> phase but with the <c>src</c> prefix replaced
- by <c>python</c>. For example, the compilation sub-phase
- function has to be named <c>python_compile</c>. These functions
- are called once for each enabled Python implementation
- and perform tasks specific to it. They are called
- with the standard implementation information variables exported
- (<c>EPYTHON</c>, <c>PYTHON</c>…).
+ Each of the implementation-specific sub-phases is named
+ according to its corresponding <c>src_*</c> phase but with
+ the <c>src_</c> prefix replaced with <c>python_</c>.
+ For example, <c>src_compile()</c> becomes
+ <c>python_compile()</c>. It is called once for each enabled
+ Python implementation. For the call scope, the default set
+ of informational variables is exported (<c>EPYTHON</c>,
+ <c>PYTHON</c>, <c>BUILD_DIR</c>, <c>PYTHONPATH</c>
+ if necessary).
</p>
<p>
- An additional <c>_all</c> suffix is appended to the common
- sub-phase functions. For example, the installation sub-phase
- function is subsequently named <c>python_install_all</c>. These
- functions are called only once in the main source directory
- and they perform tasks common to all enabled implementations.
+ Each of the implementation-common sub-phases has an additional
+ <c>_all</c> suffix appended. For example, the phase
+ corresponding to <c>src_install()</c>
+ is <c>python_install_all()</c>. It is called only once during
+ the build process. It is invoked in the main source directory.
+ No Python implementation is selected in the call scope.
</p>
<p>
The distutils-r1 eclass provides default functions for all
- per-implementation sub-phases and for <c>python_prepare_all</c>
- and <c>python_install_all</c>. If you are replacing any
- of those phase functions, you ought call the respective
- <c>distutils-r1_*</c> phase function in it.
+ implementation-specific sub-phases
+ and for <c>python_prepare_all</c> and <c>python_install_all</c>.
+ If you are defining any of those phase functions, you ought
+ call the respective distutils-r1 phase function.
</p>
<pre caption="Example of defining sub-phase functions">
@@ -534,29 +560,336 @@
in the <c>BUILD_DIR</c> variable, all calls to <c>setup.py</c>
pass additional <c>build --build-base…</c> parameters pointing
to it and the <path>lib</path> subdirectory of the build
- directory is added to <c>PYTHONPATH</c>. As a side effect,
+ directory is added to <c>PYTHONPATH</c>. As a consequence,
the package is built on the first <c>setup.py</c> invocation.
</p>
<p>
- The in-source builds are implemented for more problematic
- packages where out-of-source builds may not work due to bugs
- in the build system. They are enabled either explicitly
- when the <c>DISTUTILS_IN_SOURCE_BUILD</c> variable is set
- (to any value) or implicitly when the <c>python_prepare</c>
- (per-implementation one) sub-phase is declared.
+ The in-source builds are implemented for packages where
+ out-of-source builds are problematic. They are enabled either
+ explicitly when the <c>DISTUTILS_IN_SOURCE_BUILD</c> variable
+ is set (to any value) or implicitly
+ when the <c>python_prepare</c> sub-phase is declared.
</p>
<p>
When in-source builds are enabled, the default
<c>python_prepare_all</c> first creates a copy of all
the sources in the <c>BUILD_DIR</c> for each implementation.
- Common sub-phase functions are still executed in the source
- directory but per-implementation sub-phases are executed
- in the build directory for each implementation. There is
- no explicit linking between the source copies, therefore
- the build system is allowed to modify them freely.
+ The implementation-common sub-phase functions are still executed
+ in the source directory but the implementation-specific ones
+ are executed in the build directory for each implementation.
+ There is no explicit linking between the source copies,
+ therefore the build system is allowed to modify them freely.
+ </p>
+ </body>
+ </section>
+</chapter>
+
+<chapter id='Advanced_python_r1_functions'>
+ <title>Advanced python-r1 functions</title>
+
+ <section id='pr1_Repeating_commands_for_multiple_Python_implementations'>
+ <title>Repeating commands for multiple Python implementations</title>
+
+ <body>
+ <note>
+ This function is mostly useful for ebuilds not using
+ the <c>distutils-r1</c> eclass. For those using it, placing
+ the commands in an appropriate sub-phase function is preferred.
+ </note>
+
+ <p>
+ If it is necessary to run a command repeatedly for multiple
+ Python implementations, the <c>python_foreach_impl</c> function
+ can be used. It takes a command and a list of its paraameters/,
+ and runs it once for each Python implementation enabled.
+ The command can also name a local function.
</p>
+
+ <p>
+ The commands are run with the following environment variables
+ set:
+ </p>
+
+ <table>
+ <tr>
+ <th>Variable name</th>
+ <th>Description</th>
+ <th>Example value</th>
+ </tr>
+
+ <tr>
+ <ti><c>EPYTHON</c></ti>
+ <ti>
+ The Python implementation name.
+ </ti>
+ <ti>
+ <c>python2.7</c>, <c>pypy-c1.8</c>
+ </ti>
+ </tr>
+ <tr>
+ <ti><c>PYTHON</c></ti>
+ <ti>
+ Absolute path to the Python interpreter.
+ </ti>
+ <ti>
+ <c>/usr/bin/python2.7</c>
+ </ti>
+ </tr>
+ <tr>
+ <ti><c>BUILD_DIR</c></ti>
+ <ti>
+ The ‘standard’ build directory path for the implementation.
+ </ti>
+ <ti>
+ <c>${WORKDIR}/frobnicate-1.3-python2.7</c>
+ </ti>
+ </tr>
+ </table>
+
+ <warn>
+ Please note that <c>python_foreach_impl</c> does not create
+ the <c>BUILD_DIR</c> automatically. Unless the build system
+ does so, the ebuild author is responsible for creating it.
+ </warn>
+
+ <pre caption='Running commands for each enabled implementation'>
+src_install() {
+ <comment># I wonder how many ebuilds will copy that name…</comment>
+ <ident>sub_install</ident>() {
+ <comment># BUILD_DIR contains a module built for appropriate impl</comment>
+ <keyword>python_domodule</keyword> <var>"${BUILD_DIR}"</var>/mymodule
+ }
+
+ <comment># Run the function for each enabled implementation</comment>
+ <keyword>python_foreach_impl</keyword> <ident>sub_install</ident>
+
+ <comment># Run python_doscript (install script) for each implementation</comment>
+ <keyword>python_foreach_impl python_doscript</keyword> mymodule-ui
+}
+</pre>
+ </body>
+ </section>
+</chapter>
+
+<chapter id='Helper_functions_in_python_utils_r1_eclass'>
+ <title>Helper functions in python-utils-r1 eclass</title>
+
+ <section id="pur1_General_notes">
+ <title>General notes</title>
+
+ <body>
+ <note>
+ The functions listed in this section are directly available
+ to packages using any of the eclasses in python-r1 suite, except
+ where noted otherwise.
+ </note>
+ </body>
+ </section>
+
+ <section id="pur1_Obtaining_Python_implementation_information">
+ <title>Obtaining Python implementation information</title>
+
+ <body>
+ <p>
+ Sometimes it is necessary to obtain information specific
+ to a particular Python implementations, in particular
+ interpreter-specific paths. The <c>python-utils-r1</c> eclass
+ provides the following means of obtaining that information:
+ </p>
+
+ <ol>
+ <li><c>python_export</c> function,</li>
+ <li><c>python_export_best</c> function,</li>
+ <li>getter functions.</li>
+ </ol>
+
+ <p>
+ The <c>python_export</c> and <c>python_export_best</c> functions
+ take an optional list of variable names and export
+ the requested variables. When no variable names are passed,
+ the default variable list is used.
+ </p>
+
+ <p>
+ The <c>python_export</c> can additionally take a Python
+ implementation as a first argument, either in the form of a USE
+ flag or an <c>EPYTHON</c> value. If such a form is used,
+ the values specific to the passed implementation are exported.
+ Otherwise, the currently used implementation (the <c>EPYTHON</c>
+ environment variable) is used.
+ </p>
+
+ <p>
+ The <c>python_export_best</c> exports variables for the ‘best’
+ of the currently enabled implementations; that is, the newest
+ interpreter version from the most preferred group. These groups
+ are, in order of preference:
+ </p>
+
+ <ol>
+ <li>CPython 2,</li>
+ <li>CPython 3,</li>
+ <li>PyPy,</li>
+ <li>Jython.</li>
+ </ol>
+
+ <note>
+ The <c>python_export_best</c> function is available
+ in the <c>python-r1</c> eclass only. The <c>python-utils-r1</c>
+ eclass does not trace enabled implementations,
+ and <c>python-single-r1</c> sets the only enabled implementation
+ as the current one, making direct <c>python_export</c>
+ sufficient.
+ </note>
+
+ <p>
+ The getter functions print the value of a specific property
+ to standard output. The output can be captured using bash
+ command substitution. These functions take an optional parameter
+ specifying the requested Python implementation.
+ If not specified, the current one will be used.
+ </p>
+
+ <p>
+ The following table lists all the available variables, along
+ with the respective getter functions:
+ </p>
+
+ <table>
+ <tr>
+ <th>Variable name</th>
+ <th>Getter function</th>
+ <th>Default?</th>
+ <th>Description</th>
+ </tr>
+
+ <tr>
+ <ti><c>EPYTHON</c></ti>
+ <ti><c>python_get_EPYTHON</c></ti>
+ <ti>yes</ti>
+ <ti>
+ The Python implementation name (Gentoo-specific).
+ </ti>
+ </tr>
+ <tr>
+ <ti><c>PYTHON</c></ti>
+ <ti><c>python_get_PYTHON</c></ti>
+ <ti>yes</ti>
+ <ti>
+ Absolute path to the Python interpreter.
+ </ti>
+ </tr>
+ <tr>
+ <ti><c>PYTHON_SITEDIR</c></ti>
+ <ti><c>python_get_sitedir</c></ti>
+ <ti>no</ti>
+ <ti>
+ Path to the Python site-packages directory (where modules
+ should be installed).
+ </ti>
+ </tr>
+ </table>
+ </body>
+ </section>
+
+ <section id="pur1_Installing_Python_scripts_and_modules_manually">
+ <title>Installing Python scripts and modules manually</title>
+
+ <body>
+ <p>
+ The <c>python-utils-r1</c> eclass provides two major helpers
+ which could be used to install Python scripts and modules
+ manually. They can be used whenever the build system
+ is not capable of installing them correctly, or the package
+ maintainer wishes to install additional files.
+ </p>
+
+ <p>
+ These functions are:
+ </p>
+
+ <ol>
+ <li><c>python_domodule</c>,</li>
+ <li><c>python_doscript</c>.</li>
+ </ol>
+
+ <p>
+ The <c>python_domodule</c> helper takes a list of file
+ and/or directory names and installs the named modules
+ and packages recursively. The files are installed
+ in the <c>site-packages</c> directory by default.
+ The destination can be changed through setting
+ the <c>python_moduleroot</c> variable or using
+ the <c>python_moduleinto</c> function. It can be either
+ an absolute path or relative to the <c>site-packages</c> root.
+ </p>
+
+ <p>
+ The installed modules will be byte-compiled using the current
+ Python implementation. The selected implementation determines
+ the <c>site-packages</c> location as well.
+ </p>
+
+ <pre caption='Installing Python modules and packages'>
+src_install() {
+ <keyword>python_export</keyword> <const>python2_7</const> <var>EPYTHON PYTHON PYTHON_SITEDIR</var>
+
+ <comment># Installs /usr/lib*/python2.7/site-packages/mypackage directory</comment>
+ <keyword>python_domodule</keyword> mypackage
+
+ <comment># Installs /usr/lib*/python2.7/site-packages/epython.py (and .pyc, .pyo…)</comment>
+ <keyword>python_domodule</keyword> epython.py
+
+ <comment># Installs …/site-packages/foo/bar.py (and .pyc, .pyo…)</comment>
+ <keyword>python_moduleinto</keyword> foo
+ <keyword>python_domodule</keyword> bar.py
+
+ <comment># Installs /usr/lib/portage/pym (and compiles for py2.7)</comment>
+ <keyword>python_moduleinto</keyword> /usr/lib/portage
+ <keyword>python_domodule</keyword> pym
+
+ <comment># Installs /usr/lib*/python*/site-packages/mypackage</comment>
+ <keyword>local</keyword> <var>python_moduleroot</var>
+ <keyword>python_foreach_impl python_domodule</keyword> mypackage
+}
+</pre>
+
+ <p>
+ The <c>python_doscript</c> helper takes a list of script names
+ and installs them. The files are installed
+ in <path>/usr/bin</path> by default. The destination can
+ be changed through setting the <c>python_scriptpath</c> variable
+ or using the <c>python_scriptinto</c> function.
+ </p>
+
+ <p>
+ The installed scripts will be renamed to end
+ with an implementation-specific suffix. A wrapper will be linked
+ in place of the original name.
+ </p>
+
+ <pre caption='Installing Python scripts'>
+src_install() {
+ <keyword>python_export</keyword> <const>python3_2</const> <var>EPYTHON</var>
+
+ <comment># Installs /usr/bin/frobnicate-python3.2</comment>
+ <comment># and a wrapper symlink at /usr/bin/frobnicate</comment>
+ <keyword>python_doscript</keyword> frobnicate
+
+ <comment># Installs /usr/sbin/whyamihere-python3.2</comment>
+ <comment># and a wrapper symlink at /usr/sbin/whyamihere</comment>
+ <keyword>python_scriptinto</keyword> /usr/sbin
+ <keyword>python_doscript</keyword> whyamihere
+
+ <comment># Installs /usr/bin/myscript-* for all implementations</comment>
+ <comment># and a wrapper symlink at /usr/bin/myscript</comment>
+ <keyword>local</keyword> <var>python_scriptroot</var>
+ <keyword>python_foreach_impl python_doscript</keyword> myscript
+}
+</pre>
+
</body>
</section>
</chapter>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/Python/python-r1: dev-guide.xml
@ 2012-11-26 12:14 Michal Gorny (mgorny)
0 siblings, 0 replies; 19+ messages in thread
From: Michal Gorny (mgorny) @ 2012-11-26 12:14 UTC (permalink / raw
To: gentoo-commits
mgorny 12/11/26 12:14:31
Modified: dev-guide.xml
Log:
Mention python_optimize, a bit of clean up.
Revision Changes Path
1.3 xml/htdocs/proj/en/Python/python-r1/dev-guide.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.3&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.3&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?r1=1.2&r2=1.3
Index: dev-guide.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- dev-guide.xml 24 Nov 2012 21:34:34 -0000 1.2
+++ dev-guide.xml 26 Nov 2012 12:14:31 -0000 1.3
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.2 2012/11/24 21:34:34 mgorny Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.3 2012/11/26 12:14:31 mgorny Exp $ -->
<guide lang="en">
<title>python-r1 Developer's Guide</title>
@@ -23,8 +23,8 @@
<!-- See http://creativecommons.org/licenses/by-sa/3.0/ -->
<license version="3.0"/>
-<version>2</version>
-<date>2012-11-24</date>
+<version>3</version>
+<date>2012-11-26</date>
<chapter id="Introductory_info">
<title>Introductory information</title>
@@ -568,7 +568,7 @@
The in-source builds are implemented for packages where
out-of-source builds are problematic. They are enabled either
explicitly when the <c>DISTUTILS_IN_SOURCE_BUILD</c> variable
- is set (to any value) or implicitly
+ is set (to any value), or implicitly
when the <c>python_prepare</c> sub-phase is declared.
</p>
@@ -577,10 +577,11 @@
<c>python_prepare_all</c> first creates a copy of all
the sources in the <c>BUILD_DIR</c> for each implementation.
The implementation-common sub-phase functions are still executed
- in the source directory but the implementation-specific ones
- are executed in the build directory for each implementation.
- There is no explicit linking between the source copies,
- therefore the build system is allowed to modify them freely.
+ in the source directory, but those
+ of the implementation-specific sub-phases are executed in build
+ directories. There is no explicit linking between the source
+ copies, therefore the build system is allowed to modify them
+ freely.
</p>
</body>
</section>
@@ -889,7 +890,47 @@
<keyword>python_foreach_impl python_doscript</keyword> myscript
}
</pre>
+ </body>
+ </section>
+
+ <section id="pur1_Compiling_installed_Python_modules">
+ <title>Compiling installed Python modules</title>
+ <body>
+ <p>
+ There are a few packages which are able to install the Python
+ modules correctly but either do not compile them at all, or fail
+ to do it properly. For those packages, <c>python_optimize</c>
+ is the tool of choice.
+ </p>
+
+ <p>
+ The <c>python_optimize</c> function takes an optional list
+ of directory paths. If the list is provided, it compiles
+ all Python modules in the directories listed. Otherwise,
+ it compiles the modules installed into the standard module
+ install locations, including the <path>site-packages</path>
+ directory.
+ </p>
+
+ <p>
+ The modules are compiled using the current Python implementation
+ (<c>EPYTHON</c>).
+ </p>
+
+ <pre caption='Compiling Python modules'>
+src_install() {
+ <keyword>python_export</keyword> <const>python2_7</const> <var>EPYTHON PYTHON</var>
+
+ <comment># Compile modules in custom location using python2.7</comment>
+ <comment># (note: you can not rely on ${PYTHONPATH})</comment>
+ <keyword>python_optimize</keyword> "${D}"/usr/lib/portage/pym
+
+ <comment># Compile modules installed to site-packages</comment>
+ <comment># for all enabled implementations</comment>
+ <keyword>python_foreach_impl python_optimize</keyword>
+}
+</pre>
</body>
</section>
</chapter>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/Python/python-r1: dev-guide.xml
@ 2012-11-27 17:47 Michal Gorny (mgorny)
0 siblings, 0 replies; 19+ messages in thread
From: Michal Gorny (mgorny) @ 2012-11-27 17:47 UTC (permalink / raw
To: gentoo-commits
mgorny 12/11/27 17:47:42
Modified: dev-guide.xml
Log:
Clean up the in-source build description, minor fixes.
Revision Changes Path
1.4 xml/htdocs/proj/en/Python/python-r1/dev-guide.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.4&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.4&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?r1=1.3&r2=1.4
Index: dev-guide.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- dev-guide.xml 26 Nov 2012 12:14:31 -0000 1.3
+++ dev-guide.xml 27 Nov 2012 17:47:42 -0000 1.4
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.3 2012/11/26 12:14:31 mgorny Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.4 2012/11/27 17:47:42 mgorny Exp $ -->
<guide lang="en">
<title>python-r1 Developer's Guide</title>
@@ -23,8 +23,8 @@
<!-- See http://creativecommons.org/licenses/by-sa/3.0/ -->
<license version="3.0"/>
-<version>3</version>
-<date>2012-11-26</date>
+<version>4</version>
+<date>2012-11-27</date>
<chapter id="Introductory_info">
<title>Introductory information</title>
@@ -547,21 +547,23 @@
<p>
There are two modes of building packages with distutils-r1;
‘out-of-source builds’ (the default) and ‘in-source builds’.
- An out-of-source build uses a common source directory, reads
- files from that directory but locates the built files
- in a separate directory. An in-source build locates both
- the source and output files in the same directory.
</p>
<p>
- When an out-of-source build is used, the phase functions are run
- in the <c>${S}</c> directory. The build directory used
- for the particular implementation is stored
- in the <c>BUILD_DIR</c> variable, all calls to <c>setup.py</c>
- pass additional <c>build --build-base…</c> parameters pointing
- to it and the <path>lib</path> subdirectory of the build
- directory is added to <c>PYTHONPATH</c>. As a consequence,
- the package is built on the first <c>setup.py</c> invocation.
+ When an out-of-source build is performed, the build directory
+ (<c>${BUILD_DIR}</c>) is used to store output files, while
+ the sources are kept in their original location. Therefore,
+ the build system must not attempt to modify any of the input
+ files or write to <c>${S}</c>.
+ </p>
+
+ <p>
+ In order to support out-of-source builds, the build directory
+ is appended to <c>PYTHONPATH</c> and <c>esetup.py</c> command
+ adds build directory paths to the <c>setup.py</c> invocation.
+ Due to technical limitations of distutils, this results
+ in the package being built on the first <c>esetup.py</c>
+ invocation.
</p>
<p>
@@ -573,15 +575,11 @@
</p>
<p>
- When in-source builds are enabled, the default
- <c>python_prepare_all</c> first creates a copy of all
- the sources in the <c>BUILD_DIR</c> for each implementation.
- The implementation-common sub-phase functions are still executed
- in the source directory, but those
- of the implementation-specific sub-phases are executed in build
- directories. There is no explicit linking between the source
- copies, therefore the build system is allowed to modify them
- freely.
+ When an in-source build is performed, the build directory acts
+ both as a source and output directory. The package sources
+ are copied there first, and all implementation-specific
+ sub-phases are executed in the build directory. Therefore,
+ the build system is allowed to modify the sources freely.
</p>
</body>
</section>
@@ -603,7 +601,7 @@
<p>
If it is necessary to run a command repeatedly for multiple
Python implementations, the <c>python_foreach_impl</c> function
- can be used. It takes a command and a list of its paraameters/,
+ can be used. It takes a command and a list of its parameters
and runs it once for each Python implementation enabled.
The command can also name a local function.
</p>
@@ -750,7 +748,8 @@
to standard output. The output can be captured using bash
command substitution. These functions take an optional parameter
specifying the requested Python implementation.
- If not specified, the current one will be used.
+ If not specified, the implementation set as <c>EPYTHON</c> will
+ be used.
</p>
<p>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/Python/python-r1: dev-guide.xml
@ 2012-11-27 20:41 Michal Gorny (mgorny)
0 siblings, 0 replies; 19+ messages in thread
From: Michal Gorny (mgorny) @ 2012-11-27 20:41 UTC (permalink / raw
To: gentoo-commits
mgorny 12/11/27 20:41:25
Modified: dev-guide.xml
Log:
Explain the active implementation setting.
Revision Changes Path
1.5 xml/htdocs/proj/en/Python/python-r1/dev-guide.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.5&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.5&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?r1=1.4&r2=1.5
Index: dev-guide.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- dev-guide.xml 27 Nov 2012 17:47:42 -0000 1.4
+++ dev-guide.xml 27 Nov 2012 20:41:24 -0000 1.5
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.4 2012/11/27 17:47:42 mgorny Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.5 2012/11/27 20:41:24 mgorny Exp $ -->
<guide lang="en">
<title>python-r1 Developer's Guide</title>
@@ -23,7 +23,7 @@
<!-- See http://creativecommons.org/licenses/by-sa/3.0/ -->
<license version="3.0"/>
-<version>4</version>
+<version>5</version>
<date>2012-11-27</date>
<chapter id="Introductory_info">
@@ -200,6 +200,116 @@
</note>
</body>
</section>
+
+ <section id="ii_The_active_Python_interpreter_in_ebuild_scope">
+ <title>The active Python interpreter in ebuild scope</title>
+
+ <body>
+ <p>
+ A key concept in the workflow of python-r1 suite is the setting
+ of the active Python interpreter. Its value is stored
+ and exported in the <c>EPYTHON</c> environment variable.
+ </p>
+
+ <p>
+ The setting of active Python interpreter can affect;
+ </p>
+
+ <ol>
+ <li>
+ the interpreter used to run external Python scripts,
+ </li>
+
+ <li>
+ the implementation used by helpers,
+ such as <c>python_domodule</c> and <c>python_doscript</c>,
+ </li>
+
+ <li>
+ the default implementation for <c>python_export</c>
+ and the associated getter functions.
+ </li>
+ </ol>
+
+ <p>
+ The <c>EPYTHON</c> variable is set implicitly in the following
+ scopes;
+ </p>
+
+ <ol>
+ <li>
+ in commands and functions run by <c>python_foreach_impl</c>,
+ </li>
+
+ <li>
+ in implementation-specific sub-phases of <c>distutils-r1</c>,
+ </li>
+
+ <li>
+ in ebuilds using the <c>python-single-r1</c> eclass after
+ running <c>python-single-r1_pkg_setup</c>.
+ </li>
+ </ol>
+
+ <p>
+ If it is otherwise necessary to set the active Python
+ interpreter, it can be either set using the <c>python_export</c>
+ function or by setting the <c>EPYTHON</c> variable directly.
+ For the details on the former solution, please refer to the <uri
+ link="#pur1_Obtaining_Python_implementation_information">Obtaining
+ Python implementation information</uri> section.
+ </p>
+
+ <p>
+ If <c>EPYTHON</c> is set directly, it needs to have one
+ of the following values;
+ </p>
+
+ <ol>
+ <li>
+ <c>pythonX.Y</c> for CPython X.Y;
+ </li>
+
+ <li>
+ <c>pypy-cX.Y</c> for PyPy X.Y;
+ </li>
+
+ <li>
+ <c>jythonX.Y</c> for Jython X.Y.
+ </li>
+ </ol>
+
+ <note>
+ Please note that for <c>EPYTHON</c> to be effective to external
+ programs, it needs to be exported.
+ </note>
+
+ <pre caption='Setting EPYTHON for the function scope'>
+pkg_setup() {
+ <comment># Variant 1</comment>
+ <comment># The variables are not local, therefore the setting is preserved</comment>
+ <comment># through phase functions.</comment>
+ <keyword>python_export</keyword> <ident>python2_7</ident>
+}
+
+src_compile() {
+ <comment># Variant 2</comment>
+ <comment># The variables are kept local.</comment>
+ local <var>EPYTHON PYTHON</var>
+ <keyword>python_export</keyword> <ident>python2_7</ident>
+
+ <comment># …</comment>
+}
+
+src_install() {
+ <comment># Variant 3</comment>
+ local <var>EPYTHON</var>=<ident>python2.7</ident>
+
+ <comment># …</comment>
+}
+</pre>
+ </body>
+ </section>
</chapter>
<chapter id="The_fundamentals_of_python_r1_eclass">
@@ -712,12 +822,11 @@
</p>
<p>
- The <c>python_export</c> can additionally take a Python
+ The <c>python_export</c> function can additionally take a Python
implementation as a first argument, either in the form of a USE
flag or an <c>EPYTHON</c> value. If such a form is used,
the values specific to the passed implementation are exported.
- Otherwise, the currently used implementation (the <c>EPYTHON</c>
- environment variable) is used.
+ Otherwise, the currently active implementation is used.
</p>
<p>
@@ -827,9 +936,9 @@
</p>
<p>
- The installed modules will be byte-compiled using the current
- Python implementation. The selected implementation determines
- the <c>site-packages</c> location as well.
+ The installed modules will be byte-compiled using the currently
+ active Python implementation. The selected implementation
+ determines the <c>site-packages</c> location as well.
</p>
<pre caption='Installing Python modules and packages'>
@@ -866,8 +975,9 @@
<p>
The installed scripts will be renamed to end
- with an implementation-specific suffix. A wrapper will be linked
- in place of the original name.
+ with an implementation-specific suffix specific to the currently
+ active Python interpreter. A wrapper will be linked in place
+ of the original name.
</p>
<pre caption='Installing Python scripts'>
@@ -913,8 +1023,8 @@
</p>
<p>
- The modules are compiled using the current Python implementation
- (<c>EPYTHON</c>).
+ The modules are compiled using the currently active Python
+ implementation.
</p>
<pre caption='Compiling Python modules'>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/Python/python-r1: dev-guide.xml
@ 2012-11-28 19:49 Michal Gorny (mgorny)
0 siblings, 0 replies; 19+ messages in thread
From: Michal Gorny (mgorny) @ 2012-11-28 19:49 UTC (permalink / raw
To: gentoo-commits
mgorny 12/11/28 19:49:28
Modified: dev-guide.xml
Log:
Make the inheritance safer. Pinpoint the differences between eclasses.
Revision Changes Path
1.6 xml/htdocs/proj/en/Python/python-r1/dev-guide.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.6&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.6&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?r1=1.5&r2=1.6
Index: dev-guide.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- dev-guide.xml 27 Nov 2012 20:41:24 -0000 1.5
+++ dev-guide.xml 28 Nov 2012 19:49:28 -0000 1.6
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.5 2012/11/27 20:41:24 mgorny Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.6 2012/11/28 19:49:28 mgorny Exp $ -->
<guide lang="en">
<title>python-r1 Developer's Guide</title>
@@ -23,8 +23,8 @@
<!-- See http://creativecommons.org/licenses/by-sa/3.0/ -->
<license version="3.0"/>
-<version>5</version>
-<date>2012-11-27</date>
+<version>6</version>
+<date>2012-11-28</date>
<chapter id="Introductory_info">
<title>Introductory information</title>
@@ -192,11 +192,12 @@
</ol>
<note>
- Please note that the <c>distutils-r1</c>
- and <c>python-single-r1</c> eclasses inherit <c>python-r1</c>
- implicitly, and <c>python-r1</c> inherits
- <c>python-utils-r1</c>. There is therefore no need to ever
- inherit more than one eclass from the suite.
+ Please note that the <c>distutils-r1</c> eclass inherits
+ <c>python-r1</c> implicitly and all the eclasses inherit
+ <c>python-utils-r1</c>. <c>python-r1</c>
+ and <c>python-single-r1</c> can not be used together. There is
+ therefore no need to ever inherit more than one eclass
+ from the suite.
</note>
</body>
</section>
@@ -312,18 +313,80 @@
</section>
</chapter>
-<chapter id="The_fundamentals_of_python_r1_eclass">
- <title>The fundamentals of python-r1 eclass</title>
+<chapter id="Common_metadata_variables">
+ <title>Common metadata variables</title>
<section id="pr1_General_notes">
<title>General notes</title>
<body>
- <note>
+ <p>
The variables listed in this section apply to ebuilds using
- <c>python-single-r1</c> and <c>distutils-r1</c> eclasses as well,
- through the rules of implicit inheritance.
- </note>
+ <c>python-r1</c>, <c>distutils-r1</c>
+ and <c>python-single-r1</c> eclasses.
+ </p>
+
+ <p>
+ The following table lists the differences between the values
+ of the metadata variables according to the inherited eclass:
+ </p>
+
+ <table>
+ <tr>
+ <th>Variable</th>
+ <th>Common description</th>
+ <th>python-r1 and distutils-r1</th>
+ <th>python-single-r1</th>
+ </tr>
+
+ <tr>
+ <ti><c>IUSE</c></ti>
+ <ti>
+ USE flags for selecting the interpreter.
+ </ti>
+ <ti>
+ <c>PYTHON_TARGETS</c>
+ </ti>
+ <ti>
+ <c>PYTHON_TARGETS</c> and <c>PYTHON_SINGLE_TARGET</c>
+ </ti>
+ </tr>
+
+ <tr>
+ <ti><c>PYTHON_DEPS</c></ti>
+ <ti>
+ Dependencies upon Python interpreters.
+ </ti>
+ <ti>
+ USE-conditional upon <c>PYTHON_TARGETS</c>.
+ In <c>distutils-r1</c>, automatically added
+ to <c>RDEPEND</c> and <c>DEPEND</c>.
+ </ti>
+ <ti>
+ USE-conditional upon <c>PYTHON_SINGLE_TARGET</c>.
+ </ti>
+ </tr>
+
+ <tr>
+ <ti><c>PYTHON_USEDEP</c></ti>
+ <ti>
+ USE-dependency string for depending on other packages.
+ </ti>
+ <ti>
+ Compatible with packages using <c>python-r1</c>
+ and <c>python-distutils-ng</c>.
+ </ti>
+ <ti>
+ Compatible with packages using <c>python-r1</c>,
+ <c>python-single-r1</c> and <c>python-distutils-ng</c>.
+ </ti>
+ </tr>
+ </table>
+
+ <p>
+ The afore-mentioned variables are described in depth
+ in the sections following.
+ </p>
</body>
</section>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/Python/python-r1: dev-guide.xml
@ 2012-11-30 11:04 Michal Gorny (mgorny)
0 siblings, 0 replies; 19+ messages in thread
From: Michal Gorny (mgorny) @ 2012-11-30 11:04 UTC (permalink / raw
To: gentoo-commits
mgorny 12/11/30 11:04:16
Modified: dev-guide.xml
Log:
Replace the Python var table with simpler tables in respective sections. Fix line breaking.
Revision Changes Path
1.7 xml/htdocs/proj/en/Python/python-r1/dev-guide.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.7&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.7&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?r1=1.6&r2=1.7
Index: dev-guide.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- dev-guide.xml 28 Nov 2012 19:49:28 -0000 1.6
+++ dev-guide.xml 30 Nov 2012 11:04:15 -0000 1.7
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.6 2012/11/28 19:49:28 mgorny Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.7 2012/11/30 11:04:15 mgorny Exp $ -->
<guide lang="en">
<title>python-r1 Developer's Guide</title>
@@ -16,7 +16,7 @@
<abstract>
This guide provides a basic insight to writing ebuilds using
- the python-r1 and distutils-r1 eclasses.
+ the python‑r1 and distutils‑r1 eclasses.
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license -->
@@ -34,7 +34,7 @@
<body>
<p>
- The new Python eclasses, python-r1 and distutils-r1, are still
+ The new Python eclasses, python‑r1 and distutils‑r1, are still
considered ‘testing grade’. Although they can be used
in the tree, they must not be used on stable packages
or packages which will need to be stabilized soon. For that
@@ -114,7 +114,7 @@
<body>
<p>
- The python-r1 suite consists of four eclasses:
+ The python‑r1 suite consists of four eclasses:
</p>
<ol>
@@ -125,14 +125,14 @@
</ol>
<p>
- The <c>python-utils-r1</c> eclass is the most fundamental eclass
+ The <c>python‑utils‑r1</c> eclass is the most fundamental eclass
in the suite. It does not export any phase functions nor set
any metadata. It does not require the package to fit
any specific model.
</p>
<p>
- The <c>python-r1</c> eclass is the second fundamental eclass.
+ The <c>python‑r1</c> eclass is the second fundamental eclass.
It extends the former eclass with the metadata and variables
suited for packages supporting multiple Python implementations:
the implementation choice flags, dependency strings. It does
@@ -141,7 +141,7 @@
</p>
<p>
- The <c>distutils-r1</c> eclass extends python-r1 with a set
+ The <c>distutils‑r1</c> eclass extends python‑r1 with a set
of basic phase functions to build and install packages using
the distutils build system of the inbuilt Python module
<c>distutils</c>. It follows the common practices for build
@@ -150,8 +150,8 @@
</p>
<p>
- The <c>python-single-r1</c> eclass is an alternative
- to <c>python-r1</c> for packages which do not support being
+ The <c>python‑single‑r1</c> eclass is an alternative
+ to <c>python‑r1</c> for packages which do not support being
installed for multiple Python implementations. It exports
similar metadata and variables, and a <c>pkg_setup</c> phase
function handling the target implementation choice.
@@ -167,35 +167,35 @@
if the package supports being installed for multiple Python
implementations, the Python part of it is unconditional
and uses the distutils build system (or one very similar),
- use the <c>distutils-r1</c> eclass;
+ use the <c>distutils‑r1</c> eclass;
</li>
<li>
if the package supports being installed for multiple Python
implementations separately and installs Python modules,
- scripts or embeds Python, use <c>python-r1</c>;
+ scripts or embeds Python, use <c>python‑r1</c>;
</li>
<li>
if the package can be installed for a single Python
implementation only and installs Python modules, scripts
- or embeds Python, use <c>python-single-r1</c>;
+ or embeds Python, use <c>python‑single‑r1</c>;
</li>
<li>
if the package has a specific or loose connection to Python,
installs Python modules for multiple implementations
in a common location, or has any other special needs,
- consider using <c>python-utils-r1</c> (although you may
+ consider using <c>python‑utils‑r1</c> (although you may
not need any eclass at all).
</li>
</ol>
<note>
- Please note that the <c>distutils-r1</c> eclass inherits
- <c>python-r1</c> implicitly and all the eclasses inherit
- <c>python-utils-r1</c>. <c>python-r1</c>
- and <c>python-single-r1</c> can not be used together. There is
+ Please note that the <c>distutils‑r1</c> eclass inherits
+ <c>python‑r1</c> implicitly and all the eclasses inherit
+ <c>python‑utils‑r1</c>. <c>python‑r1</c>
+ and <c>python‑single‑r1</c> can not be used together. There is
therefore no need to ever inherit more than one eclass
from the suite.
</note>
@@ -207,7 +207,7 @@
<body>
<p>
- A key concept in the workflow of python-r1 suite is the setting
+ A key concept in the workflow of python‑r1 suite is the setting
of the active Python interpreter. Its value is stored
and exported in the <c>EPYTHON</c> environment variable.
</p>
@@ -243,12 +243,12 @@
</li>
<li>
- in implementation-specific sub-phases of <c>distutils-r1</c>,
+ in implementation-specific sub-phases of <c>distutils‑r1</c>,
</li>
<li>
- in ebuilds using the <c>python-single-r1</c> eclass after
- running <c>python-single-r1_pkg_setup</c>.
+ in ebuilds using the <c>python‑single‑r1</c> eclass after
+ running <c>python‑single‑r1_pkg_setup</c>.
</li>
</ol>
@@ -320,89 +320,28 @@
<title>General notes</title>
<body>
- <p>
+ <note>
The variables listed in this section apply to ebuilds using
- <c>python-r1</c>, <c>distutils-r1</c>
- and <c>python-single-r1</c> eclasses.
- </p>
-
- <p>
- The following table lists the differences between the values
- of the metadata variables according to the inherited eclass:
- </p>
-
- <table>
- <tr>
- <th>Variable</th>
- <th>Common description</th>
- <th>python-r1 and distutils-r1</th>
- <th>python-single-r1</th>
- </tr>
-
- <tr>
- <ti><c>IUSE</c></ti>
- <ti>
- USE flags for selecting the interpreter.
- </ti>
- <ti>
- <c>PYTHON_TARGETS</c>
- </ti>
- <ti>
- <c>PYTHON_TARGETS</c> and <c>PYTHON_SINGLE_TARGET</c>
- </ti>
- </tr>
-
- <tr>
- <ti><c>PYTHON_DEPS</c></ti>
- <ti>
- Dependencies upon Python interpreters.
- </ti>
- <ti>
- USE-conditional upon <c>PYTHON_TARGETS</c>.
- In <c>distutils-r1</c>, automatically added
- to <c>RDEPEND</c> and <c>DEPEND</c>.
- </ti>
- <ti>
- USE-conditional upon <c>PYTHON_SINGLE_TARGET</c>.
- </ti>
- </tr>
-
- <tr>
- <ti><c>PYTHON_USEDEP</c></ti>
- <ti>
- USE-dependency string for depending on other packages.
- </ti>
- <ti>
- Compatible with packages using <c>python-r1</c>
- and <c>python-distutils-ng</c>.
- </ti>
- <ti>
- Compatible with packages using <c>python-r1</c>,
- <c>python-single-r1</c> and <c>python-distutils-ng</c>.
- </ti>
- </tr>
- </table>
-
- <p>
- The afore-mentioned variables are described in depth
- in the sections following.
- </p>
+ <c>python‑r1</c>, <c>distutils‑r1</c>
+ and <c>python‑single‑r1</c> eclasses.
+ </note>
</body>
</section>
<section id="pr1_Listing_supported_Python_implementations">
- <title>Listing supported Python implementations</title>
+ <title>Listing supported Python implementations
+ (PYTHON_COMPAT)</title>
<body>
<p>
The first and most important task in writing ebuilds both
- for python-r1 and distutils-r1 is to specify the list of Python
+ for python‑r1 and distutils‑r1 is to specify the list of Python
implementations supported by the ebuild.
</p>
<p>
This list is specified using the <c>PYTHON_COMPAT</c> variable.
- It is an obligatory array which has to be declared before
+ It is an obligatory array which need be declared before
the <c>inherit</c> command. It should list <e>all</e> supported
implementations using the following naming scheme:
</p>
@@ -436,26 +375,26 @@
<comment># Python 2.6+ and compliant implementations.</comment>
<ident>PYTHON_COMPAT</ident>=( python{2_6,2_7} pypy{1_8,1_9} )
-<comment># inherit goes below PYTHON_COMPAT</comment>
+<comment># inherit follows PYTHON_COMPAT</comment>
<keyword>inherit</keyword> python-r1
</pre>
</body>
</section>
<section id="pr1_Depending_on_Python">
- <title>Depending on Python</title>
+ <title>Depending on Python (PYTHON_DEPS)</title>
<body>
<note>
Please note that this section applies to the sole use
- of <c>python-r1</c> or <c>python-single-r1</c> only.
- The <c>distutils-r1</c> eclass unconditionally adds this
+ of <c>python‑r1</c> or <c>python‑single‑r1</c> only.
+ The <c>distutils‑r1</c> eclass unconditionally adds this
dependency.
</note>
<p>
In order to efficiently handle various kinds of package
- dependencies on Python, the python-r1 eclass does not set
+ dependencies on Python, the python‑r1 eclass does not set
the ebuild dependencies directly. Instead, it prepares
the proper dependency string and stores it in a variable named
<c>PYTHON_DEPS</c>.
@@ -471,8 +410,8 @@
<p>
The ebuild should reference the <c>PYTHON_DEPS</c> variable
- in <c>RDEPEND</c> and/or <c>DEPEND</c> as necessary. It may need
- to put those dependencies into an appropriate USE-conditional
+ in <c>RDEPEND</c> and/or <c>DEPEND</c> as necessary. Those
+ dependencies may require use of an appropriate USE-conditional
block.
</p>
@@ -487,18 +426,57 @@
<comment># USE-conditional Python run-time dependency.</comment>
<ident>RDEPEND</ident>="<const>python?</const> ( ${PYTHON_DEPS} )"
</pre>
+
+ <p>
+ The actual value assigned to this variable differs according
+ to the inherited eclass as listed in the following table:
+ </p>
+
+ <table>
+ <tr>
+ <th>Eclass</th>
+ <th>Dependency type</th>
+ <th>Example value</th>
+ </tr>
+
+ <tr>
+ <ti><c>python‑r1</c> & <c>distutils‑r1</c></ti>
+ <ti>
+ USE-conditional upon <c>PYTHON_TARGETS</c>
+ </ti>
+ <ti>
+ <c>
+ python_targets_python2_6? ( dev-lang/python:2.6 )
+ python_targets_python2_7? ( dev-lang/python:2.7 )
+ </c>
+ </ti>
+ </tr>
+
+ <tr>
+ <ti><c>python‑single‑r1</c></ti>
+ <ti>
+ USE-conditional upon <c>PYTHON_SINGLE_TARGET</c>
+ </ti>
+ <ti>
+ <c>
+ python_single_target_python2_6? ( dev-lang/python:2.6 )
+ python_single_target_python2_7? ( dev-lang/python:2.7 )
+ </c>
+ </ti>
+ </tr>
+ </table>
</body>
</section>
<section id="pr1_Depending_on_other_Python_packages">
- <title>Depending on other Python packages</title>
+ <title>Depending on other Python packages (PYTHON_USEDEP)</title>
<body>
<p>
There are currently two kinds of Python packages in the tree;
one which explicitly specify enabled Python implementations via
- <c>PYTHON_TARGETS</c>, and consists of ebuilds using python-r1
- and python-distutils-ng eclasses, the other which lacks such
+ <c>PYTHON_TARGETS</c>, and consists of ebuilds using python‑r1
+ and python‑distutils‑ng eclasses, the other which lacks such
a support. These are packages using the ‘original’
python.eclass.
</p>
@@ -529,7 +507,7 @@
</p>
<pre caption="Example use of PYTHON_USEDEP">
-<comment># Simple dependency on a python-r1 package.</comment>
+<comment># Simple dependency on a python‑r1 package.</comment>
<ident>RDEPEND</ident>="<const>dev-python/setuptools</const>[${PYTHON_USEDEP}]"
<comment># Dependency with additional USE flags requested.</comment>
@@ -538,11 +516,47 @@
<comment># Dependency on a package using python.eclass.</comment>
<ident>RDEPEND</ident>="<const>dev-python/wxpython:2.8</const>"
</pre>
+
+ <p>
+ The compatibility of <c>PYTHON_USEDEP</c> with ebuilds using
+ different eclasses according to the inherited eclass is listed
+ in the following table:
+ </p>
+
+ <table>
+ <tr>
+ <th>Eclass</th>
+ <th>Compatible with</th>
+ <th>Example value</th>
+ </tr>
+
+ <tr>
+ <ti><c>python‑r1</c> & <c>distutils‑r1</c></ti>
+ <ti>
+ <c>python‑r1</c>, <c>python‑distutils‑ng</c>
+ </ti>
+ <ti>
+ <c>python_targets_python2_6?,python_targets_python2_7?</c>
+ </ti>
+ </tr>
+
+ <tr>
+ <ti><c>python‑single‑r1</c></ti>
+ <ti>
+ <c>python‑r1</c>,
+ <c>python‑single‑r1</c>,
+ <c>python‑distutils‑ng</c>
+ </ti>
+ <ti>
+ <c>python_targets_python2_6?,python_targets_python2_7?,python_single_target_python2_6(+)?,python_single_target_python2_7(+)?</c>
+ </ti>
+ </tr>
+ </table>
</body>
</section>
<section id="pr1_Requesting_optional_Python_features">
- <title>Requesting optional Python features (modules)</title>
+ <title>Requesting optional Python features (PYTHON_REQ_USE)</title>
<body>
<p>
@@ -600,21 +614,21 @@
</chapter>
<chapter id="The_distutils_r1_eclass">
- <title>The distutils-r1 eclass</title>
+ <title>The distutils‑r1 eclass</title>
<section id="dr1_Tasks_performed_by_distutils_r1">
- <title>Tasks performed by distutils-r1</title>
+ <title>Tasks performed by distutils‑r1</title>
<body>
<p>
- The distutils-r1 exports a set of phase functions performing
+ The distutils‑r1 exports a set of phase functions performing
common tasks related to building and installing the package.
In many cases, those tasks will suffice for a typical Python
package.
</p>
<p>
- The tasks performed by distutils-r1 are (in execution order):
+ The tasks performed by distutils‑r1 are (in execution order):
</p>
<ol>
@@ -657,7 +671,7 @@
<body>
<p>
- The distutils-r1 eclass utilises a mechanism inspired by phase
+ The distutils‑r1 eclass utilises a mechanism inspired by phase
functions to make writing ebuilds relatively easy. For each
of the <c>src_*</c> phases, two ‘partial’ phases are used;
the implementation-specific sub-phase
@@ -686,11 +700,11 @@
</p>
<p>
- The distutils-r1 eclass provides default functions for all
+ The distutils‑r1 eclass provides default functions for all
implementation-specific sub-phases
and for <c>python_prepare_all</c> and <c>python_install_all</c>.
If you are defining any of those phase functions, you ought
- call the respective distutils-r1 phase function.
+ call the respective distutils‑r1 phase function.
</p>
<pre caption="Example of defining sub-phase functions">
@@ -718,7 +732,7 @@
<body>
<p>
- There are two modes of building packages with distutils-r1;
+ There are two modes of building packages with distutils‑r1;
‘out-of-source builds’ (the default) and ‘in-source builds’.
</p>
@@ -759,7 +773,7 @@
</chapter>
<chapter id='Advanced_python_r1_functions'>
- <title>Advanced python-r1 functions</title>
+ <title>Advanced python‑r1 functions</title>
<section id='pr1_Repeating_commands_for_multiple_Python_implementations'>
<title>Repeating commands for multiple Python implementations</title>
@@ -767,7 +781,7 @@
<body>
<note>
This function is mostly useful for ebuilds not using
- the <c>distutils-r1</c> eclass. For those using it, placing
+ the <c>distutils‑r1</c> eclass. For those using it, placing
the commands in an appropriate sub-phase function is preferred.
</note>
@@ -846,7 +860,7 @@
</chapter>
<chapter id='Helper_functions_in_python_utils_r1_eclass'>
- <title>Helper functions in python-utils-r1 eclass</title>
+ <title>Helper functions in python‑utils‑r1 eclass</title>
<section id="pur1_General_notes">
<title>General notes</title>
@@ -854,7 +868,7 @@
<body>
<note>
The functions listed in this section are directly available
- to packages using any of the eclasses in python-r1 suite, except
+ to packages using any of the eclasses in python‑r1 suite, except
where noted otherwise.
</note>
</body>
@@ -867,7 +881,7 @@
<p>
Sometimes it is necessary to obtain information specific
to a particular Python implementations, in particular
- interpreter-specific paths. The <c>python-utils-r1</c> eclass
+ interpreter-specific paths. The <c>python‑utils‑r1</c> eclass
provides the following means of obtaining that information:
</p>
@@ -908,9 +922,9 @@
<note>
The <c>python_export_best</c> function is available
- in the <c>python-r1</c> eclass only. The <c>python-utils-r1</c>
+ in the <c>python‑r1</c> eclass only. The <c>python‑utils‑r1</c>
eclass does not trace enabled implementations,
- and <c>python-single-r1</c> sets the only enabled implementation
+ and <c>python‑single‑r1</c> sets the only enabled implementation
as the current one, making direct <c>python_export</c>
sufficient.
</note>
@@ -971,7 +985,7 @@
<body>
<p>
- The <c>python-utils-r1</c> eclass provides two major helpers
+ The <c>python‑utils‑r1</c> eclass provides two major helpers
which could be used to install Python scripts and modules
manually. They can be used whenever the build system
is not capable of installing them correctly, or the package
^ permalink raw reply [flat|nested] 19+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/Python/python-r1: dev-guide.xml
@ 2012-12-01 9:27 Michal Gorny (mgorny)
0 siblings, 0 replies; 19+ messages in thread
From: Michal Gorny (mgorny) @ 2012-12-01 9:27 UTC (permalink / raw
To: gentoo-commits
mgorny 12/12/01 09:27:17
Modified: dev-guide.xml
Log:
Further clean up, describe python-any-r1.
Revision Changes Path
1.8 xml/htdocs/proj/en/Python/python-r1/dev-guide.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.8&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.8&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?r1=1.7&r2=1.8
Index: dev-guide.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- dev-guide.xml 30 Nov 2012 11:04:15 -0000 1.7
+++ dev-guide.xml 1 Dec 2012 09:27:16 -0000 1.8
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.7 2012/11/30 11:04:15 mgorny Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.8 2012/12/01 09:27:16 mgorny Exp $ -->
<guide lang="en">
<title>python-r1 Developer's Guide</title>
@@ -23,8 +23,8 @@
<!-- See http://creativecommons.org/licenses/by-sa/3.0/ -->
<license version="3.0"/>
-<version>6</version>
-<date>2012-11-28</date>
+<version>7</version>
+<date>2012-12-01</date>
<chapter id="Introductory_info">
<title>Introductory information</title>
@@ -114,14 +114,15 @@
<body>
<p>
- The python‑r1 suite consists of four eclasses:
+ The python‑r1 suite consists of five eclasses:
</p>
<ol>
<li><c>python-utils-r1</c>,</li>
<li><c>python-r1</c>,</li>
<li><c>distutils-r1</c>,</li>
- <li><c>python-single-r1</c>.</li>
+ <li><c>python-single-r1</c>,</li>
+ <li><c>python-any-r1</c>.</li>
</ol>
<p>
@@ -158,36 +159,57 @@
</p>
<p>
+ The <c>python‑any‑r1</c> eclass is designed to be used
+ on packages which do not need explicit implementation choice
+ or rely on specific implementation installed being invariable.
+ This mostly involves packages having strictly build-time
+ dependency on Python. It exports metadata suitable for setting
+ an appropriate dependency, and a <c>pkg_setup</c> phase function
+ handling finding the best installed implementation.
+ </p>
+
+ <p>
The choice of eclass for your package could follow the following
algorithm:
</p>
<ol>
<li>
- if the package supports being installed for multiple Python
- implementations, the Python part of it is unconditional
- and uses the distutils build system (or one very similar),
- use the <c>distutils‑r1</c> eclass;
+ If the package supports being installed for multiple Python
+ implementations;
+
+ <ol>
+ <li>
+ and if the Python-related content uses the distutils build
+ system and is free of being conditional to a USE flag,
+ then use <c>distutils‑r1</c>;
+ </li>
+
+ <li>
+ and if the Python-related content is conditional
+ to a USE flag or the package uses non-distutils build
+ system, then use <c>python‑r1</c>.
+ </li>
+ </ol>
</li>
<li>
- if the package supports being installed for multiple Python
- implementations separately and installs Python modules,
- scripts or embeds Python, use <c>python‑r1</c>;
+ If the package can be installed for a single Python
+ implementation only and installs Python modules, scripts
+ or embeds Python, then use <c>python‑single‑r1</c>.
</li>
<li>
- if the package can be installed for a single Python
- implementation only and installs Python modules, scripts
- or embeds Python, use <c>python‑single‑r1</c>;
+ If the package has a strictly build-time dependency on Python
+ or installs Python modules or scripts in a common variant
+ for multiple Python implementations,
+ then use <c>python‑any‑r1</c>.
</li>
<li>
- if the package has a specific or loose connection to Python,
- installs Python modules for multiple implementations
- in a common location, or has any other special needs,
- consider using <c>python‑utils‑r1</c> (although you may
- not need any eclass at all).
+ If the package has a specific or loose connection to Python
+ where no other eclass serves the intended purpose,
+ then consider using <c>python‑utils‑r1</c>.
</li>
</ol>
@@ -440,7 +462,7 @@
</tr>
<tr>
- <ti><c>python‑r1</c> & <c>distutils‑r1</c></ti>
+ <ti><c>python‑r1</c></ti>
<ti>
USE-conditional upon <c>PYTHON_TARGETS</c>
</ti>
@@ -464,6 +486,18 @@
</c>
</ti>
</tr>
+
+ <tr>
+ <ti><c>python‑any‑r1</c></ti>
+ <ti>
+ unconditional, satisfied by any supported version
+ </ti>
+ <ti>
+ <c>
+ || ( dev-lang/python:2.7 dev-lang/python:2.6 )
+ </c>
+ </ti>
+ </tr>
</table>
</body>
</section>
@@ -518,20 +552,20 @@
</pre>
<p>
- The compatibility of <c>PYTHON_USEDEP</c> with ebuilds using
- different eclasses according to the inherited eclass is listed
- in the following table:
+ The compatibilities of <c>PYTHON_USEDEP</c> with packages
+ using different eclasses according to the inherited eclass
+ of the ebuild being developed are listed in the following table:
</p>
<table>
<tr>
<th>Eclass</th>
- <th>Compatible with</th>
+ <th>Compatible with packages using</th>
<th>Example value</th>
</tr>
<tr>
- <ti><c>python‑r1</c> & <c>distutils‑r1</c></ti>
+ <ti><c>python‑r1</c></ti>
<ti>
<c>python‑r1</c>, <c>python‑distutils‑ng</c>
</ti>
@@ -544,13 +578,23 @@
<ti><c>python‑single‑r1</c></ti>
<ti>
<c>python‑r1</c>,
- <c>python‑single‑r1</c>,
- <c>python‑distutils‑ng</c>
+ <c>python‑distutils‑ng</c>,
+ <c>python‑single‑r1</c>
</ti>
<ti>
<c>python_targets_python2_6?,python_targets_python2_7?,python_single_target_python2_6(+)?,python_single_target_python2_7(+)?</c>
</ti>
</tr>
+
+ <tr>
+ <ti><c>python‑any‑r1</c></ti>
+ <ti>
+ not used in eclass
+ </ti>
+ <ti>
+ n/a
+ </ti>
+ </tr>
</table>
</body>
</section>
@@ -564,7 +608,7 @@
belongs to the Python implementation itself but is not always
available. The availability can depend both on Python version
and USE flags. These features can be divided into two types;
- those having replacement modules and those lacking them.
+ those having replacement packages and those lacking them.
</p>
<p>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/Python/python-r1: dev-guide.xml
@ 2012-12-06 16:15 Michal Gorny (mgorny)
0 siblings, 0 replies; 19+ messages in thread
From: Michal Gorny (mgorny) @ 2012-12-06 16:15 UTC (permalink / raw
To: gentoo-commits
mgorny 12/12/06 16:15:21
Modified: dev-guide.xml
Log:
Describe parallel builds.
Revision Changes Path
1.9 xml/htdocs/proj/en/Python/python-r1/dev-guide.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.9&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.9&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?r1=1.8&r2=1.9
Index: dev-guide.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- dev-guide.xml 1 Dec 2012 09:27:16 -0000 1.8
+++ dev-guide.xml 6 Dec 2012 16:15:21 -0000 1.9
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.8 2012/12/01 09:27:16 mgorny Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.9 2012/12/06 16:15:21 mgorny Exp $ -->
<guide lang="en">
<title>python-r1 Developer's Guide</title>
@@ -23,8 +23,8 @@
<!-- See http://creativecommons.org/licenses/by-sa/3.0/ -->
<license version="3.0"/>
-<version>7</version>
-<date>2012-12-01</date>
+<version>8</version>
+<date>2012-12-06</date>
<chapter id="Introductory_info">
<title>Introductory information</title>
@@ -814,6 +814,52 @@
</p>
</body>
</section>
+
+ <section id="dr1_Parallel_build_support">
+ <title>Parallel build support</title>
+
+ <body>
+ <p>
+ A parallel build occurs when more than one task is performed
+ concurrently. For example, many common build systems including
+ autotools and cmake compile multiple files in parallel to make
+ a better use of the computing power of modern multicore CPUs
+ and multiprocessor systems.
+ </p>
+
+ <p>
+ Sadly, distutils itself is not capable of parallel builds,
+ making the build of multiple Python extensions inefficient
+ and time-consuming. In order to circumvent that limitation,
+ the distutils‑r1 eclass runs the whole build process
+ for multiple Python implementations in parallel.
+ </p>
+
+ <p>
+ This usually causes no issues itself but it can trigger issues
+ consequent to the modifying of source files by the build system.
+ Those issues can generally be managed by enabling the in-source
+ build option by setting <c>DISTUTILS_IN_SOURCE_BUILD</c>
+ to a non-null value.
+ </p>
+
+ <p>
+ When a parallel build is performed, the ebuild is disallowed
+ from modifying installed files during
+ the implementation-specific sub-phase. Any changes necessary
+ need be delayed until the implementation-common sub-phase.
+ Otherwise, the files are prone to being clobbered in the middle
+ of performing the change.
+ </p>
+
+ <p>
+ If the build system itself actually uses a parallel build
+ (e.g. distutils running <c>make</c>) or any other issue
+ makes parallel build undesirable, it can be disabled by setting
+ <c>DISTUTILS_NO_PARALLEL_BUILD</c> to a non-null value.
+ </p>
+ </body>
+ </section>
</chapter>
<chapter id='Advanced_python_r1_functions'>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/Python/python-r1: dev-guide.xml
@ 2012-12-07 18:00 Michal Gorny (mgorny)
0 siblings, 0 replies; 19+ messages in thread
From: Michal Gorny (mgorny) @ 2012-12-07 18:00 UTC (permalink / raw
To: gentoo-commits
mgorny 12/12/07 18:00:57
Modified: dev-guide.xml
Log:
Update wrt exporting best implementation data.
Revision Changes Path
1.10 xml/htdocs/proj/en/Python/python-r1/dev-guide.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.10&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.10&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?r1=1.9&r2=1.10
Index: dev-guide.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- dev-guide.xml 6 Dec 2012 16:15:21 -0000 1.9
+++ dev-guide.xml 7 Dec 2012 18:00:57 -0000 1.10
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.9 2012/12/06 16:15:21 mgorny Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.10 2012/12/07 18:00:57 mgorny Exp $ -->
<guide lang="en">
<title>python-r1 Developer's Guide</title>
@@ -23,8 +23,8 @@
<!-- See http://creativecommons.org/licenses/by-sa/3.0/ -->
<license version="3.0"/>
-<version>8</version>
-<date>2012-12-06</date>
+<version>9</version>
+<date>2012-12-07</date>
<chapter id="Introductory_info">
<title>Introductory information</title>
@@ -735,12 +735,16 @@
</p>
<p>
- Each of the implementation-common sub-phases has an additional
- <c>_all</c> suffix appended. For example, the phase
- corresponding to <c>src_install()</c>
- is <c>python_install_all()</c>. It is called only once during
- the build process. It is invoked in the main source directory.
- No Python implementation is selected in the call scope.
+ Each of the implementation-common sub-phases has
+ the suffix <c>_all</c> appended. For example,
+ the <c>python_install_all()</c> sub-phase corresponds
+ to <c>src_install()</c>. It is called only once during the build
+ process. It is invoked in the main source directory.
+ For the call scope, the variables corresponding to the best
+ enabled Python implementation are exported. The value
+ of <c>BUILD_DIR</c> is preserved, however, and the value
+ specific to the best implementation is stored
+ as <c>BEST_BUILD_DIR</c>.
</p>
<p>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/Python/python-r1: dev-guide.xml
@ 2012-12-09 14:39 Michal Gorny (mgorny)
0 siblings, 0 replies; 19+ messages in thread
From: Michal Gorny (mgorny) @ 2012-12-09 14:39 UTC (permalink / raw
To: gentoo-commits
mgorny 12/12/09 14:39:47
Modified: dev-guide.xml
Log:
Descibe python-single-r1 and python-any-r1.
Revision Changes Path
1.11 xml/htdocs/proj/en/Python/python-r1/dev-guide.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.11&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.11&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?r1=1.10&r2=1.11
Index: dev-guide.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- dev-guide.xml 7 Dec 2012 18:00:57 -0000 1.10
+++ dev-guide.xml 9 Dec 2012 14:39:47 -0000 1.11
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.10 2012/12/07 18:00:57 mgorny Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.11 2012/12/09 14:39:47 mgorny Exp $ -->
<guide lang="en">
<title>python-r1 Developer's Guide</title>
@@ -23,8 +23,8 @@
<!-- See http://creativecommons.org/licenses/by-sa/3.0/ -->
<license version="3.0"/>
-<version>9</version>
-<date>2012-12-07</date>
+<version>10</version>
+<date>2012-12-09</date>
<chapter id="Introductory_info">
<title>Introductory information</title>
@@ -953,6 +953,140 @@
</section>
</chapter>
+<chapter id='Eclasses_for_use_of_a_single_Python_implementation'>
+ <title>Eclasses for use of a single Python implementation</title>
+
+ <section id="spi_Introduction">
+ <title>Introduction</title>
+
+ <body>
+ <p>
+ The python‑r1 suite provides two eclasses for work with a single
+ Python implementation:
+ </p>
+
+ <ol>
+ <li><c>python-single-r1</c>,</li>
+
+ <li><c>python-any-r1</c>.</li>
+ </ol>
+
+ <p>
+ The python‑single‑r1 eclass is intended for packages where
+ the choice of the used Python implementation is made available
+ to the user. This group includes packages which install Python
+ modules or scripts specific to the chosen implementation.
+ </p>
+
+ <p>
+ The python‑any‑r1 eclass is intended for packages which
+ are not bound to a single Python implementation and its
+ selection, therefore, is unimportant. These are mostly
+ packages with build-time tools written in Python.
+ </p>
+
+ <p>
+ Both eclasses share the same core API being a superset of the core
+ python‑r1 API. It includes;
+ </p>
+
+ <ol>
+ <li>
+ use of <c>PYTHON_COMPAT</c> to list supported Python
+ implementations,
+ </li>
+
+ <li>
+ setting of <c>PYTHON_DEPS</c> to a proper dependency string,
+ respecting <c>PYTHON_REQ_USE</c>,
+ </li>
+
+ <li>
+ export of <c>pkg_setup()</c> phase function which performs
+ the choice of Python implementation and exports
+ implementation-specific variables.
+ </li>
+ </ol>
+
+ <p>
+ It should be noted that if the Python-related code in the ebuild
+ is conditional upon a USE flag, a proper USE-conditional need
+ be used around <c>${PYTHON_DEPS}</c>
+ and the <c>python-single-r1_pkg_setup</c>
+ or <c>python-any-r1_pkg_setup</c> invocation need be used
+ conditionally.
+ </p>
+
+ <pre caption='Example conditional use of python‑single‑r1'>
+<var>PYTHON_COMPAT</var>=( python{2_6,2_7} )
+inherit <ident>python-single-r1</ident>
+
+<var>IUSE</var>="<const>python</const>"
+
+<var>RDEPEND</var>="<const>python?</const> ( <ident>${PYTHON_DEPS}</ident> )"
+<var>DEPEND</var>=${RDEPEND}
+
+pkg_setup() {
+ <keyword>use</keyword> <const>python</const> && <keyword>python-single-r1_pkg_setup</keyword>
+}
+</pre>
+ </body>
+ </section>
+
+ <section id="spi_python_single_r1">
+ <title>python‑single‑r1</title>
+
+ <body>
+ <p>
+ The python‑single‑r1 eclass, much alike python‑r1, provides
+ an explicit implementation choice with the help of USE flags.
+ However, in order not to collide with common setups enabling
+ multiple Python implementations, it uses a different variable —
+ <c>PYTHON_SINGLE_TARGET</c>.
+ </p>
+
+ <p>
+ The <c>python-single-r1_pkg_setup</c> phase function obtains
+ the value of <c>PYTHON_SINGLE_TARGET</c> and exports the default
+ set of variables specific to the chosen Python implementation.
+ </p>
+ </body>
+ </section>
+
+ <section id="spi_python_any_r1">
+ <title>python‑any‑r1</title>
+
+ <body>
+ <p>
+ The python‑any‑r1 eclass performs an implicit choice of Python
+ implementation. It accepts any of the supported Python
+ interpreters (therefore using an any-of dependency
+ in <c>PYTHON_DEPS</c>), and chooses the best installed one.
+ </p>
+
+ <p>
+ The <c>python-any-r1_pkg_setup</c> phase function obtains
+ the best Python implementation installed. The choice algorithm
+ follows one used by python‑exec tool, that is in order:
+ </p>
+
+ <ol>
+ <li>
+ the implementation specified in <c>EPYTHON</c>,
+ </li>
+
+ <li>
+ the implementation chosen by eselect‑python,
+ </li>
+
+ <li>
+ the default implementation preference.
+ </li>
+ </ol>
+ </body>
+ </section>
+</chapter>
+
<chapter id='Helper_functions_in_python_utils_r1_eclass'>
<title>Helper functions in python‑utils‑r1 eclass</title>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/Python/python-r1: dev-guide.xml
@ 2013-01-04 22:34 Michal Gorny (mgorny)
0 siblings, 0 replies; 19+ messages in thread
From: Michal Gorny (mgorny) @ 2013-01-04 22:34 UTC (permalink / raw
To: gentoo-commits
mgorny 13/01/04 22:34:46
Modified: dev-guide.xml
Log:
Remove outdated note on lack of single-impl packages support.
Revision Changes Path
1.12 xml/htdocs/proj/en/Python/python-r1/dev-guide.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.12&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.12&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?r1=1.11&r2=1.12
Index: dev-guide.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- dev-guide.xml 9 Dec 2012 14:39:47 -0000 1.11
+++ dev-guide.xml 4 Jan 2013 22:34:46 -0000 1.12
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.11 2012/12/09 14:39:47 mgorny Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.12 2013/01/04 22:34:46 mgorny Exp $ -->
<guide lang="en">
<title>python-r1 Developer's Guide</title>
@@ -46,8 +46,6 @@
It should be noted that the -r1 eclasses are not a drop-in
replacement for python.eclass. They differ in design and goals.
At the moment, they also lack some of the functionality.
- The most important gap is lack of support for packages
- not supporting installation for multiple Python implementations.
</p>
</body>
</section>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/Python/python-r1: dev-guide.xml
@ 2013-01-11 21:16 Michal Gorny (mgorny)
0 siblings, 0 replies; 19+ messages in thread
From: Michal Gorny (mgorny) @ 2013-01-11 21:16 UTC (permalink / raw
To: gentoo-commits
mgorny 13/01/11 21:16:23
Modified: dev-guide.xml
Log:
Remove outdated info on when to use.
The eclass has been blessed for stable use already.
Revision Changes Path
1.13 xml/htdocs/proj/en/Python/python-r1/dev-guide.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.13&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.13&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?r1=1.12&r2=1.13
Index: dev-guide.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- dev-guide.xml 4 Jan 2013 22:34:46 -0000 1.12
+++ dev-guide.xml 11 Jan 2013 21:16:23 -0000 1.13
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.12 2013/01/04 22:34:46 mgorny Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.13 2013/01/11 21:16:23 mgorny Exp $ -->
<guide lang="en">
<title>python-r1 Developer's Guide</title>
@@ -23,33 +23,12 @@
<!-- See http://creativecommons.org/licenses/by-sa/3.0/ -->
<license version="3.0"/>
-<version>10</version>
-<date>2012-12-09</date>
+<version>11</version>
+<date>2013-01-11</date>
<chapter id="Introductory_info">
<title>Introductory information</title>
- <section id="ii_When_to_use">
- <title>When to use?</title>
-
- <body>
- <p>
- The new Python eclasses, python‑r1 and distutils‑r1, are still
- considered ‘testing grade’. Although they can be used
- in the tree, they must not be used on stable packages
- or packages which will need to be stabilized soon. For that
- reason, it is usually a good idea to revbump the package when
- converting.
- </p>
-
- <p>
- It should be noted that the -r1 eclasses are not a drop-in
- replacement for python.eclass. They differ in design and goals.
- At the moment, they also lack some of the functionality.
- </p>
- </body>
- </section>
-
<section id="ii_Types_of_Python_packages">
<title>Types of Python packages</title>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/Python/python-r1: dev-guide.xml
@ 2013-01-12 23:34 Michal Gorny (mgorny)
0 siblings, 0 replies; 19+ messages in thread
From: Michal Gorny (mgorny) @ 2013-01-12 23:34 UTC (permalink / raw
To: gentoo-commits
mgorny 13/01/12 23:34:43
Modified: dev-guide.xml
Log:
Remove the notion of BEST_BUILD_DIR. It is simply BUILD_DIR now.
Revision Changes Path
1.14 xml/htdocs/proj/en/Python/python-r1/dev-guide.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.14&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.14&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?r1=1.13&r2=1.14
Index: dev-guide.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- dev-guide.xml 11 Jan 2013 21:16:23 -0000 1.13
+++ dev-guide.xml 12 Jan 2013 23:34:43 -0000 1.14
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.13 2013/01/11 21:16:23 mgorny Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.14 2013/01/12 23:34:43 mgorny Exp $ -->
<guide lang="en">
<title>python-r1 Developer's Guide</title>
@@ -718,10 +718,7 @@
to <c>src_install()</c>. It is called only once during the build
process. It is invoked in the main source directory.
For the call scope, the variables corresponding to the best
- enabled Python implementation are exported. The value
- of <c>BUILD_DIR</c> is preserved, however, and the value
- specific to the best implementation is stored
- as <c>BEST_BUILD_DIR</c>.
+ enabled Python implementation are exported.
</p>
<p>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/Python/python-r1: dev-guide.xml
@ 2013-01-30 11:30 Michal Gorny (mgorny)
0 siblings, 0 replies; 19+ messages in thread
From: Michal Gorny (mgorny) @ 2013-01-30 11:30 UTC (permalink / raw
To: gentoo-commits
mgorny 13/01/30 11:30:21
Modified: dev-guide.xml
Log:
Update the examples to not mention pypy1.8
Revision Changes Path
1.15 xml/htdocs/proj/en/Python/python-r1/dev-guide.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.15&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.15&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?r1=1.14&r2=1.15
Index: dev-guide.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- dev-guide.xml 12 Jan 2013 23:34:43 -0000 1.14
+++ dev-guide.xml 30 Jan 2013 11:30:21 -0000 1.15
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.14 2013/01/12 23:34:43 mgorny Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.15 2013/01/30 11:30:21 mgorny Exp $ -->
<guide lang="en">
<title>python-r1 Developer's Guide</title>
@@ -23,8 +23,8 @@
<!-- See http://creativecommons.org/licenses/by-sa/3.0/ -->
<license version="3.0"/>
-<version>11</version>
-<date>2013-01-11</date>
+<version>12</version>
+<date>2013-01-30</date>
<chapter id="Introductory_info">
<title>Introductory information</title>
@@ -372,7 +372,7 @@
<ident>PYTHON_COMPAT</ident>=( python{2_5,2_6,2_7,3_1,3_2,3_3} )
<comment># Python 2.6+ and compliant implementations.</comment>
-<ident>PYTHON_COMPAT</ident>=( python{2_6,2_7} pypy{1_8,1_9} )
+<ident>PYTHON_COMPAT</ident>=( python{2_6,2_7} pypy{1_9,2_0} )
<comment># inherit follows PYTHON_COMPAT</comment>
<keyword>inherit</keyword> python-r1
@@ -879,7 +879,7 @@
The Python implementation name.
</ti>
<ti>
- <c>python2.7</c>, <c>pypy-c1.8</c>
+ <c>python2.7</c>, <c>pypy-c2.0</c>
</ti>
</tr>
<tr>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/Python/python-r1: dev-guide.xml
@ 2013-02-13 11:40 Michal Gorny (mgorny)
0 siblings, 0 replies; 19+ messages in thread
From: Michal Gorny (mgorny) @ 2013-02-13 11:40 UTC (permalink / raw
To: gentoo-commits
mgorny 13/02/13 11:40:31
Modified: dev-guide.xml
Log:
Update on eclass choice, hints for python.eclass users.
Revision Changes Path
1.16 xml/htdocs/proj/en/Python/python-r1/dev-guide.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.16&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.16&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?r1=1.15&r2=1.16
Index: dev-guide.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- dev-guide.xml 30 Jan 2013 11:30:21 -0000 1.15
+++ dev-guide.xml 13 Feb 2013 11:40:31 -0000 1.16
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.15 2013/01/30 11:30:21 mgorny Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.16 2013/02/13 11:40:31 mgorny Exp $ -->
<guide lang="en">
<title>python-r1 Developer's Guide</title>
@@ -23,69 +23,12 @@
<!-- See http://creativecommons.org/licenses/by-sa/3.0/ -->
<license version="3.0"/>
-<version>12</version>
-<date>2013-01-30</date>
+<version>13</version>
+<date>2013-02-13</date>
<chapter id="Introductory_info">
<title>Introductory information</title>
- <section id="ii_Types_of_Python_packages">
- <title>Types of Python packages</title>
-
- <body>
- <p>
- The Python packages in Gentoo, that is packages either
- installing Python modules or embedding the Python interpreter,
- can be divided into three main groups:
- </p>
-
- <ol>
- <li>
- packages which are capable of being installed for multiple
- selected Python implementations;
- </li>
-
- <li>
- packages which are capable of being installed for a single
- chosen Python implementation only;
- </li>
-
- <li>
- packages being installed independently of Python
- implementations.
- </li>
- </ol>
-
- <p>
- The first group is the most common one and comprises most
- of the packages installing Python modules and/or scripts.
- The installed files are either directed
- to implementation-specific directories or renamed in order
- to allow installing multiple copies, one for each enabled Python
- implementation. This way, the packages can cleanly guarantee
- that the particular packages can be used with any implementation
- installed.
- </p>
-
- <p>
- The second group consists of most of the packages embedding
- the Python interpreter or installing Python bindings as a part
- of a more general build system. The installed files can
- be installed only once and only for one chosen Python
- implementation. The package can't be used by any other
- installed Python implementation.
- </p>
-
- <p>
- The third group comprises mostly very specific packages which
- do not fit the regular Python package model. This includes
- packages which are installed externally and can be used
- by multiple Python implementations,
- such as <c>sys-apps/portage</c>.
- </p>
- </body>
- </section>
-
<section id="ii_Purpose_of_the_eclasses">
<title>Purpose of the eclasses</title>
@@ -97,13 +40,13 @@
<ol>
<li><c>python-utils-r1</c>,</li>
<li><c>python-r1</c>,</li>
- <li><c>distutils-r1</c>,</li>
<li><c>python-single-r1</c>,</li>
- <li><c>python-any-r1</c>.</li>
+ <li><c>python-any-r1</c>,</li>
+ <li><c>distutils-r1</c>.</li>
</ol>
<p>
- The <c>python‑utils‑r1</c> eclass is the most fundamental eclass
+ The <c>python‑utils‑r1</c> eclass is the utility eclass
in the suite. It does not export any phase functions nor set
any metadata. It does not require the package to fit
any specific model.
@@ -119,15 +62,6 @@
</p>
<p>
- The <c>distutils‑r1</c> eclass extends python‑r1 with a set
- of basic phase functions to build and install packages using
- the distutils build system of the inbuilt Python module
- <c>distutils</c>. It follows the common practices for build
- system eclasses, including patching and installing
- documentation.
- </p>
-
- <p>
The <c>python‑single‑r1</c> eclass is an alternative
to <c>python‑r1</c> for packages which do not support being
installed for multiple Python implementations. It exports
@@ -146,57 +80,74 @@
</p>
<p>
+ The <c>distutils‑r1</c> eclass extends the suite with a set
+ of basic phase functions to build and install packages using
+ the distutils build system of the inbuilt Python module
+ <c>distutils</c>. It follows the common practices for build
+ system eclasses, including patching and installing
+ documentation.
+ </p>
+
+ <p>
The choice of eclass for your package could follow the following
algorithm:
</p>
<ol>
<li>
- If the package supports being installed for multiple Python
- implementations;
+ If the package uses the distutils build system,
+ then use <c>distutils‑r1</c>.
+ </li>
- <ol>
- <li>
- and if the Python-related content uses the distutils build
- system and is free of being conditional to a USE flag,
- then use <c>distutils‑r1</c>;
- </li>
-
- <li>
- and if the Python-related content is conditional
- to a USE flag or the package uses non-distutils build
- system, then use <c>python‑r1</c>.
- </li>
- </ol>
+ <li>
+ If the package installs Python modules or scripts which can
+ be simultaneously installed for multiple Python
+ implementations, use <c>python‑r1</c>.
</li>
<li>
- If the package can be installed for a single Python
- implementation only and installs Python modules, scripts
+ If the package installs Python modules or scripts which can
+ be installed for a single Python implementation only,
or embeds Python, then use <c>python‑single‑r1</c>.
</li>
<li>
- If the package has a strictly build-time dependency on Python
- or installs Python modules or scripts in a common variant
- for multiple Python implementations,
+ If the package has a strictly build-time dependency on Python,
then use <c>python‑any‑r1</c>.
</li>
+ </ol>
+
+ <p>
+ A conversion from <c>python.eclass</c> can follow the following
+ algorithm:
+ </p>
+
+ <ol>
+ <li>
+ If the package inherits <c>distutils</c>, then use
+ <c>distutils‑r1</c>.
+ </li>
<li>
- If the package has a specific or loose connection to Python
- where no other eclass serves the intended purpose,
- then consider using <c>python‑utils‑r1</c>.
+ If the package enables <c>SUPPORT_PYTHON_ABIS</c>, then use
+ <c>python‑r1</c>.
+ </li>
+
+ <li>
+ If the package has run-time dependency on Python,
+ then use <c>python‑single‑r1</c>.
+ </li>
+
+ <li>
+ If the package has only build-time dependency on Python,
+ then use <c>python‑any‑r1</c>.
</li>
</ol>
<note>
- Please note that the <c>distutils‑r1</c> eclass inherits
- <c>python‑r1</c> implicitly and all the eclasses inherit
- <c>python‑utils‑r1</c>. <c>python‑r1</c>
- and <c>python‑single‑r1</c> can not be used together. There is
- therefore no need to ever inherit more than one eclass
- from the suite.
+ Please note that you always inherit only the best match
+ of the fore-mentioned eclasses. Other relevant eclasses
+ are inherited implicitly.
</note>
</body>
</section>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/Python/python-r1: dev-guide.xml
@ 2013-02-15 14:35 Michal Gorny (mgorny)
0 siblings, 0 replies; 19+ messages in thread
From: Michal Gorny (mgorny) @ 2013-02-15 14:35 UTC (permalink / raw
To: gentoo-commits
mgorny 13/02/15 14:35:18
Modified: dev-guide.xml
Log:
Improve on PYTHON_USEDEP and pkg_setup in appropriate eclasses.
Revision Changes Path
1.17 xml/htdocs/proj/en/Python/python-r1/dev-guide.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.17&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.17&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?r1=1.16&r2=1.17
Index: dev-guide.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- dev-guide.xml 13 Feb 2013 11:40:31 -0000 1.16
+++ dev-guide.xml 15 Feb 2013 14:35:18 -0000 1.17
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.16 2013/02/13 11:40:31 mgorny Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.17 2013/02/15 14:35:18 mgorny Exp $ -->
<guide lang="en">
<title>python-r1 Developer's Guide</title>
@@ -23,8 +23,8 @@
<!-- See http://creativecommons.org/licenses/by-sa/3.0/ -->
<license version="3.0"/>
-<version>13</version>
-<date>2013-02-13</date>
+<version>14</version>
+<date>2013-02-15</date>
<chapter id="Introductory_info">
<title>Introductory information</title>
@@ -435,37 +435,32 @@
<body>
<p>
- There are currently two kinds of Python packages in the tree;
- one which explicitly specify enabled Python implementations via
- <c>PYTHON_TARGETS</c>, and consists of ebuilds using python‑r1
- and python‑distutils‑ng eclasses, the other which lacks such
- a support. These are packages using the ‘original’
- python.eclass.
+ Whenever two Python packages involve one of the packages loading
+ Python modules installed by the other, both packages need
+ to have the support for the same Python implementations enabled.
+ That constraint needs to be enforced through the use
+ of <c>PYTHON_USEDEP</c> variable.
</p>
<p>
- When a dependency against a package supporting
- <c>PYTHON_TARGETS</c> is to be expressed, a USE dependency
- should be specified to ensure that the dependencies
- are installed for all required Python implementations.
- The eclass provides the necessary dependency string fragment
- in <c>PYTHON_USEDEP</c> variable.
+ The <c>PYTHON_USEDEP</c> variable is set unconditionally
+ by the eclass. It contains a bare compact USE dependency string
+ which can be used directly in dependency specifications.
</p>
<p>
- The <c>PYTHON_USEDEP</c> variable is set unconditionally
- by the eclass. It contains a bare compact USE dependency string,
- enforcing a requirement on all selected Python implementations.
+ It should be noted that dependencies not involving direct Python
+ module loading do not require <c>PYTHON_USEDEP</c>. For example,
+ running external Python scripts does not need those constraints
+ enforced.
</p>
<p>
- Depending on packages not supporting <c>PYTHON_TARGETS</c>
- is discouraged. Whenever possible, please consider migrating
- the dependant package instead. Such a dependency is unable
- to enforce the fore-mentioned requirement, therefore making
- the user vulnerable to unclear nuisance failures.
- The dependencies on packages of that kind are expressed using
- the regular (simple) dependency syntax.
+ <c>PYTHON_USEDEP</c> can not be used against packages
+ not supporting <c>PYTHON_TARGETS</c>. Developers are strongly
+ encouraged to convert dependencies before committing the actual
+ package. If that is not feasible, the dependency has to omit
+ the use of <c>PYTHON_USEDEP</c>.
</p>
<pre caption="Example use of PYTHON_USEDEP">
@@ -942,6 +937,12 @@
conditionally.
</p>
+ <note>
+ The setting of active Python interpreter is done automatically
+ in the <c>pkg_setup</c> phase. Therefore, there is no need
+ for a function similar to <c>python_set_active_version</c>.
+ </note>
+
<pre caption='Example conditional use of python‑single‑r1'>
<var>PYTHON_COMPAT</var>=( python{2_6,2_7} )
inherit <ident>python-single-r1</ident>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/Python/python-r1: dev-guide.xml
@ 2013-06-27 2:09 Robin H. Johnson (robbat2)
0 siblings, 0 replies; 19+ messages in thread
From: Robin H. Johnson (robbat2) @ 2013-06-27 2:09 UTC (permalink / raw
To: gentoo-commits
robbat2 13/06/27 02:09:56
Modified: dev-guide.xml
Log:
Fix usage of really annoying UTF dash "‑", this prevented me from searching for strings in the website.
Revision Changes Path
1.18 xml/htdocs/proj/en/Python/python-r1/dev-guide.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.18&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.18&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?r1=1.17&r2=1.18
Index: dev-guide.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v
retrieving revision 1.17
retrieving revision 1.18
diff -p -w -b -B -u -u -r1.17 -r1.18
--- dev-guide.xml 15 Feb 2013 14:35:18 -0000 1.17
+++ dev-guide.xml 27 Jun 2013 02:09:56 -0000 1.18
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.17 2013/02/15 14:35:18 mgorny Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.18 2013/06/27 02:09:56 robbat2 Exp $ -->
<guide lang="en">
<title>python-r1 Developer's Guide</title>
@@ -16,7 +16,7 @@
<abstract>
This guide provides a basic insight to writing ebuilds using
- the python‑r1 and distutils‑r1 eclasses.
+ the python-r1 and distutils-r1 eclasses.
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license -->
@@ -34,7 +34,7 @@
<body>
<p>
- The python‑r1 suite consists of five eclasses:
+ The python-r1 suite consists of five eclasses:
</p>
<ol>
@@ -46,14 +46,14 @@
</ol>
<p>
- The <c>python‑utils‑r1</c> eclass is the utility eclass
+ The <c>python-utils-r1</c> eclass is the utility eclass
in the suite. It does not export any phase functions nor set
any metadata. It does not require the package to fit
any specific model.
</p>
<p>
- The <c>python‑r1</c> eclass is the second fundamental eclass.
+ The <c>python-r1</c> eclass is the second fundamental eclass.
It extends the former eclass with the metadata and variables
suited for packages supporting multiple Python implementations:
the implementation choice flags, dependency strings. It does
@@ -62,15 +62,15 @@
</p>
<p>
- The <c>python‑single‑r1</c> eclass is an alternative
- to <c>python‑r1</c> for packages which do not support being
+ The <c>python-single-r1</c> eclass is an alternative
+ to <c>python-r1</c> for packages which do not support being
installed for multiple Python implementations. It exports
similar metadata and variables, and a <c>pkg_setup</c> phase
function handling the target implementation choice.
</p>
<p>
- The <c>python‑any‑r1</c> eclass is designed to be used
+ The <c>python-any-r1</c> eclass is designed to be used
on packages which do not need explicit implementation choice
or rely on specific implementation installed being invariable.
This mostly involves packages having strictly build-time
@@ -80,7 +80,7 @@
</p>
<p>
- The <c>distutils‑r1</c> eclass extends the suite with a set
+ The <c>distutils-r1</c> eclass extends the suite with a set
of basic phase functions to build and install packages using
the distutils build system of the inbuilt Python module
<c>distutils</c>. It follows the common practices for build
@@ -96,24 +96,24 @@
<ol>
<li>
If the package uses the distutils build system,
- then use <c>distutils‑r1</c>.
+ then use <c>distutils-r1</c>.
</li>
<li>
If the package installs Python modules or scripts which can
be simultaneously installed for multiple Python
- implementations, use <c>python‑r1</c>.
+ implementations, use <c>python-r1</c>.
</li>
<li>
If the package installs Python modules or scripts which can
be installed for a single Python implementation only,
- or embeds Python, then use <c>python‑single‑r1</c>.
+ or embeds Python, then use <c>python-single-r1</c>.
</li>
<li>
If the package has a strictly build-time dependency on Python,
- then use <c>python‑any‑r1</c>.
+ then use <c>python-any-r1</c>.
</li>
</ol>
@@ -125,22 +125,22 @@
<ol>
<li>
If the package inherits <c>distutils</c>, then use
- <c>distutils‑r1</c>.
+ <c>distutils-r1</c>.
</li>
<li>
If the package enables <c>SUPPORT_PYTHON_ABIS</c>, then use
- <c>python‑r1</c>.
+ <c>python-r1</c>.
</li>
<li>
If the package has run-time dependency on Python,
- then use <c>python‑single‑r1</c>.
+ then use <c>python-single-r1</c>.
</li>
<li>
If the package has only build-time dependency on Python,
- then use <c>python‑any‑r1</c>.
+ then use <c>python-any-r1</c>.
</li>
</ol>
@@ -157,7 +157,7 @@
<body>
<p>
- A key concept in the workflow of python‑r1 suite is the setting
+ A key concept in the workflow of python-r1 suite is the setting
of the active Python interpreter. Its value is stored
and exported in the <c>EPYTHON</c> environment variable.
</p>
@@ -193,12 +193,12 @@
</li>
<li>
- in implementation-specific sub-phases of <c>distutils‑r1</c>,
+ in implementation-specific sub-phases of <c>distutils-r1</c>,
</li>
<li>
- in ebuilds using the <c>python‑single‑r1</c> eclass after
- running <c>python‑single‑r1_pkg_setup</c>.
+ in ebuilds using the <c>python-single-r1</c> eclass after
+ running <c>python-single-r1_pkg_setup</c>.
</li>
</ol>
@@ -272,8 +272,8 @@ src_install() {
<body>
<note>
The variables listed in this section apply to ebuilds using
- <c>python‑r1</c>, <c>distutils‑r1</c>
- and <c>python‑single‑r1</c> eclasses.
+ <c>python-r1</c>, <c>distutils-r1</c>
+ and <c>python-single-r1</c> eclasses.
</note>
</body>
</section>
@@ -285,7 +285,7 @@ src_install() {
<body>
<p>
The first and most important task in writing ebuilds both
- for python‑r1 and distutils‑r1 is to specify the list of Python
+ for python-r1 and distutils-r1 is to specify the list of Python
implementations supported by the ebuild.
</p>
@@ -337,14 +337,14 @@ src_install() {
<body>
<note>
Please note that this section applies to the sole use
- of <c>python‑r1</c> or <c>python‑single‑r1</c> only.
- The <c>distutils‑r1</c> eclass unconditionally adds this
+ of <c>python-r1</c> or <c>python-single-r1</c> only.
+ The <c>distutils-r1</c> eclass unconditionally adds this
dependency.
</note>
<p>
In order to efficiently handle various kinds of package
- dependencies on Python, the python‑r1 eclass does not set
+ dependencies on Python, the python-r1 eclass does not set
the ebuild dependencies directly. Instead, it prepares
the proper dependency string and stores it in a variable named
<c>PYTHON_DEPS</c>.
@@ -390,7 +390,7 @@ src_install() {
</tr>
<tr>
- <ti><c>python‑r1</c></ti>
+ <ti><c>python-r1</c></ti>
<ti>
USE-conditional upon <c>PYTHON_TARGETS</c>
</ti>
@@ -403,7 +403,7 @@ src_install() {
</tr>
<tr>
- <ti><c>python‑single‑r1</c></ti>
+ <ti><c>python-single-r1</c></ti>
<ti>
USE-conditional upon <c>PYTHON_SINGLE_TARGET</c>
</ti>
@@ -416,7 +416,7 @@ src_install() {
</tr>
<tr>
- <ti><c>python‑any‑r1</c></ti>
+ <ti><c>python-any-r1</c></ti>
<ti>
unconditional, satisfied by any supported version
</ti>
@@ -464,7 +464,7 @@ src_install() {
</p>
<pre caption="Example use of PYTHON_USEDEP">
-<comment># Simple dependency on a python‑r1 package.</comment>
+<comment># Simple dependency on a python-r1 package.</comment>
<ident>RDEPEND</ident>="<const>dev-python/setuptools</const>[${PYTHON_USEDEP}]"
<comment># Dependency with additional USE flags requested.</comment>
@@ -488,9 +488,9 @@ src_install() {
</tr>
<tr>
- <ti><c>python‑r1</c></ti>
+ <ti><c>python-r1</c></ti>
<ti>
- <c>python‑r1</c>, <c>python‑distutils‑ng</c>
+ <c>python-r1</c>, <c>python-distutils-ng</c>
</ti>
<ti>
<c>python_targets_python2_6?,python_targets_python2_7?</c>
@@ -498,11 +498,11 @@ src_install() {
</tr>
<tr>
- <ti><c>python‑single‑r1</c></ti>
+ <ti><c>python-single-r1</c></ti>
<ti>
- <c>python‑r1</c>,
- <c>python‑distutils‑ng</c>,
- <c>python‑single‑r1</c>
+ <c>python-r1</c>,
+ <c>python-distutils-ng</c>,
+ <c>python-single-r1</c>
</ti>
<ti>
<c>python_targets_python2_6?,python_targets_python2_7?,python_single_target_python2_6(+)?,python_single_target_python2_7(+)?</c>
@@ -510,7 +510,7 @@ src_install() {
</tr>
<tr>
- <ti><c>python‑any‑r1</c></ti>
+ <ti><c>python-any-r1</c></ti>
<ti>
not used in eclass
</ti>
@@ -581,21 +581,21 @@ src_install() {
</chapter>
<chapter id="The_distutils_r1_eclass">
- <title>The distutils‑r1 eclass</title>
+ <title>The distutils-r1 eclass</title>
<section id="dr1_Tasks_performed_by_distutils_r1">
- <title>Tasks performed by distutils‑r1</title>
+ <title>Tasks performed by distutils-r1</title>
<body>
<p>
- The distutils‑r1 exports a set of phase functions performing
+ The distutils-r1 exports a set of phase functions performing
common tasks related to building and installing the package.
In many cases, those tasks will suffice for a typical Python
package.
</p>
<p>
- The tasks performed by distutils‑r1 are (in execution order):
+ The tasks performed by distutils-r1 are (in execution order):
</p>
<ol>
@@ -638,7 +638,7 @@ src_install() {
<body>
<p>
- The distutils‑r1 eclass utilises a mechanism inspired by phase
+ The distutils-r1 eclass utilises a mechanism inspired by phase
functions to make writing ebuilds relatively easy. For each
of the <c>src_*</c> phases, two ‘partial’ phases are used;
the implementation-specific sub-phase
@@ -668,11 +668,11 @@ src_install() {
</p>
<p>
- The distutils‑r1 eclass provides default functions for all
+ The distutils-r1 eclass provides default functions for all
implementation-specific sub-phases
and for <c>python_prepare_all</c> and <c>python_install_all</c>.
If you are defining any of those phase functions, you ought
- call the respective distutils‑r1 phase function.
+ call the respective distutils-r1 phase function.
</p>
<pre caption="Example of defining sub-phase functions">
@@ -700,7 +700,7 @@ src_install() {
<body>
<p>
- There are two modes of building packages with distutils‑r1;
+ There are two modes of building packages with distutils-r1;
‘out-of-source builds’ (the default) and ‘in-source builds’.
</p>
@@ -755,7 +755,7 @@ src_install() {
Sadly, distutils itself is not capable of parallel builds,
making the build of multiple Python extensions inefficient
and time-consuming. In order to circumvent that limitation,
- the distutils‑r1 eclass runs the whole build process
+ the distutils-r1 eclass runs the whole build process
for multiple Python implementations in parallel.
</p>
@@ -787,7 +787,7 @@ src_install() {
</chapter>
<chapter id='Advanced_python_r1_functions'>
- <title>Advanced python‑r1 functions</title>
+ <title>Advanced python-r1 functions</title>
<section id='pr1_Repeating_commands_for_multiple_Python_implementations'>
<title>Repeating commands for multiple Python implementations</title>
@@ -795,7 +795,7 @@ src_install() {
<body>
<note>
This function is mostly useful for ebuilds not using
- the <c>distutils‑r1</c> eclass. For those using it, placing
+ the <c>distutils-r1</c> eclass. For those using it, placing
the commands in an appropriate sub-phase function is preferred.
</note>
@@ -881,7 +881,7 @@ src_install() {
<body>
<p>
- The python‑r1 suite provides two eclasses for work with a single
+ The python-r1 suite provides two eclasses for work with a single
Python implementation:
</p>
@@ -892,14 +892,14 @@ src_install() {
</ol>
<p>
- The python‑single‑r1 eclass is intended for packages where
+ The python-single-r1 eclass is intended for packages where
the choice of the used Python implementation is made available
to the user. This group includes packages which install Python
modules or scripts specific to the chosen implementation.
</p>
<p>
- The python‑any‑r1 eclass is intended for packages which
+ The python-any-r1 eclass is intended for packages which
are not bound to a single Python implementation and its
selection, therefore, is unimportant. These are mostly
packages with build-time tools written in Python.
@@ -907,7 +907,7 @@ src_install() {
<p>
Both eclasses share the same core API being a superset of the core
- python‑r1 API. It includes;
+ python-r1 API. It includes;
</p>
<ol>
@@ -943,7 +943,7 @@ src_install() {
for a function similar to <c>python_set_active_version</c>.
</note>
- <pre caption='Example conditional use of python‑single‑r1'>
+ <pre caption='Example conditional use of python-single-r1'>
<var>PYTHON_COMPAT</var>=( python{2_6,2_7} )
inherit <ident>python-single-r1</ident>
@@ -960,11 +960,11 @@ pkg_setup() {
</section>
<section id="spi_python_single_r1">
- <title>python‑single‑r1</title>
+ <title>python-single-r1</title>
<body>
<p>
- The python‑single‑r1 eclass, much alike python‑r1, provides
+ The python-single-r1 eclass, much alike python-r1, provides
an explicit implementation choice with the help of USE flags.
However, in order not to collide with common setups enabling
multiple Python implementations, it uses a different variable —
@@ -980,11 +980,11 @@ pkg_setup() {
</section>
<section id="spi_python_any_r1">
- <title>python‑any‑r1</title>
+ <title>python-any-r1</title>
<body>
<p>
- The python‑any‑r1 eclass performs an implicit choice of Python
+ The python-any-r1 eclass performs an implicit choice of Python
implementation. It accepts any of the supported Python
interpreters (therefore using an any-of dependency
in <c>PYTHON_DEPS</c>), and chooses the best installed one.
@@ -993,7 +993,7 @@ pkg_setup() {
<p>
The <c>python-any-r1_pkg_setup</c> phase function obtains
the best Python implementation installed. The choice algorithm
- follows one used by python‑exec tool, that is in order:
+ follows one used by python-exec tool, that is in order:
</p>
<ol>
@@ -1002,7 +1002,7 @@ pkg_setup() {
</li>
<li>
- the implementation chosen by eselect‑python,
+ the implementation chosen by eselect-python,
</li>
<li>
@@ -1014,7 +1014,7 @@ pkg_setup() {
</chapter>
<chapter id='Helper_functions_in_python_utils_r1_eclass'>
- <title>Helper functions in python‑utils‑r1 eclass</title>
+ <title>Helper functions in python-utils-r1 eclass</title>
<section id="pur1_General_notes">
<title>General notes</title>
@@ -1022,7 +1022,7 @@ pkg_setup() {
<body>
<note>
The functions listed in this section are directly available
- to packages using any of the eclasses in python‑r1 suite, except
+ to packages using any of the eclasses in python-r1 suite, except
where noted otherwise.
</note>
</body>
@@ -1035,7 +1035,7 @@ pkg_setup() {
<p>
Sometimes it is necessary to obtain information specific
to a particular Python implementations, in particular
- interpreter-specific paths. The <c>python‑utils‑r1</c> eclass
+ interpreter-specific paths. The <c>python-utils-r1</c> eclass
provides the following means of obtaining that information:
</p>
@@ -1076,9 +1076,9 @@ pkg_setup() {
<note>
The <c>python_export_best</c> function is available
- in the <c>python‑r1</c> eclass only. The <c>python‑utils‑r1</c>
+ in the <c>python-r1</c> eclass only. The <c>python-utils-r1</c>
eclass does not trace enabled implementations,
- and <c>python‑single‑r1</c> sets the only enabled implementation
+ and <c>python-single-r1</c> sets the only enabled implementation
as the current one, making direct <c>python_export</c>
sufficient.
</note>
@@ -1139,7 +1139,7 @@ pkg_setup() {
<body>
<p>
- The <c>python‑utils‑r1</c> eclass provides two major helpers
+ The <c>python-utils-r1</c> eclass provides two major helpers
which could be used to install Python scripts and modules
manually. They can be used whenever the build system
is not capable of installing them correctly, or the package
^ permalink raw reply [flat|nested] 19+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/Python/python-r1: dev-guide.xml
@ 2013-09-20 21:15 Michal Gorny (mgorny)
0 siblings, 0 replies; 19+ messages in thread
From: Michal Gorny (mgorny) @ 2013-09-20 21:15 UTC (permalink / raw
To: gentoo-commits
mgorny 13/09/20 21:15:36
Modified: dev-guide.xml
Log:
Mark the dev guide obsolete in favor of wiki docs.
Revision Changes Path
1.19 xml/htdocs/proj/en/Python/python-r1/dev-guide.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.19&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.19&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?r1=1.18&r2=1.19
Index: dev-guide.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- dev-guide.xml 27 Jun 2013 02:09:56 -0000 1.18
+++ dev-guide.xml 20 Sep 2013 21:15:36 -0000 1.19
@@ -1,9 +1,10 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.18 2013/06/27 02:09:56 robbat2 Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.19 2013/09/20 21:15:36 mgorny Exp $ -->
-<guide lang="en">
+<guide lang="en" disclaimer="obsolete"
+ redirect="http://wiki.gentoo.org/wiki/Python/Eclasses">
<title>python-r1 Developer's Guide</title>
<author title="Author">
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2013-09-20 21:15 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-20 21:15 [gentoo-commits] gentoo commit in xml/htdocs/proj/en/Python/python-r1: dev-guide.xml Michal Gorny (mgorny)
-- strict thread matches above, loose matches on Subject: below --
2013-06-27 2:09 Robin H. Johnson (robbat2)
2013-02-15 14:35 Michal Gorny (mgorny)
2013-02-13 11:40 Michal Gorny (mgorny)
2013-01-30 11:30 Michal Gorny (mgorny)
2013-01-12 23:34 Michal Gorny (mgorny)
2013-01-11 21:16 Michal Gorny (mgorny)
2013-01-04 22:34 Michal Gorny (mgorny)
2012-12-09 14:39 Michal Gorny (mgorny)
2012-12-07 18:00 Michal Gorny (mgorny)
2012-12-06 16:15 Michal Gorny (mgorny)
2012-12-01 9:27 Michal Gorny (mgorny)
2012-11-30 11:04 Michal Gorny (mgorny)
2012-11-28 19:49 Michal Gorny (mgorny)
2012-11-27 20:41 Michal Gorny (mgorny)
2012-11-27 17:47 Michal Gorny (mgorny)
2012-11-26 12:14 Michal Gorny (mgorny)
2012-11-24 21:34 Michal Gorny (mgorny)
2012-11-10 8:26 Michal Gorny (mgorny)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox