Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 321879 - x11-misc/revelation: Verify and potentially improve Python-related code
Summary: x11-misc/revelation: Verify and potentially improve Python-related code
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: Alexandre Rostovtsev (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 308257
  Show dependency tree
 
Reported: 2010-05-28 17:58 UTC by Arfrever Frehtes Taifersar Arahesis (RETIRED)
Modified: 2012-05-22 16:46 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
revelation.patch (revelation.patch,1.25 KB, patch)
2011-06-30 20:51 UTC, Arfrever Frehtes Taifersar Arahesis (RETIRED)
Details | Diff
ebuild patch (revelation.patch,1.24 KB, patch)
2011-11-29 15:10 UTC, Ian Delaney (RETIRED)
Details | Diff
revised ebuild patch (revelation.patch,1.50 KB, patch)
2011-11-29 19:51 UTC, Ian Delaney (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Arfrever Frehtes Taifersar Arahesis (RETIRED) gentoo-dev 2010-05-28 17:58:12 UTC
- If this package can be used as a library and installs Python modules
  (*.so or *.py) into site-packages directories, then consider supporting
  installation for multiple Python versions.
  Please read section "Types of packages" in documentation [1] to decide
  if this package can support installation for multiple Python versions.

- Ensure that the ebuilds do not use deprecated functions or variables.

- Please check if Python 3 is supported by this package. You can temporarily
  set Python 3 as main active version of Python to properly test if this
  package supports Python 3.

- If this package does not support Python 3:
  - Specify dependency on Python 2.
    You can use PYTHON_DEPEND helper variable, which should be set before
    inheriting of python eclass.
    Please read section "Specification of dependency on Python" in
    documentation [1].

  - If this package cannot support installation for multiple versions of
    Python, then set active version of Python using
    python_set_active_version().

  - Ensure that shebangs in installed scripts specify correct version of
    Python. If shebangs are too generic (e.g. '#!/usr/bin/python'), then you
    can use python_convert_shebangs() to convert shebangs.
    (Wrapper scripts generated by python_generate_wrapper_scripts() do not
    require any changes.)
    Please read section "Shebangs in installed scripts" in documentation [1].

  - To ensure that changes applied to the ebuilds are sufficient, please
    temporarily set Python 3 as main active version of Python and test if
    this package can be properly installed and if it works at run time.

Please see documentation [1] for more details.
[1] http://www.gentoo.org/proj/en/Python/developersguide.xml
Comment 1 Arfrever Frehtes Taifersar Arahesis (RETIRED) gentoo-dev 2011-06-30 20:51:26 UTC
Created attachment 278739 [details, diff]
revelation.patch
Comment 2 Ian Delaney (RETIRED) gentoo-dev 2011-11-29 15:10:20 UTC
Created attachment 294183 [details, diff]
ebuild patch

a long time since you made that one.  I can't figure the install, it's totally trashed
Comment 3 Ian Delaney (RETIRED) gentoo-dev 2011-11-29 19:51:31 UTC
Created attachment 294233 [details, diff]
revised ebuild patch

I got some help. The python related dep packages narrow this package down to only installing and subsequently running on python2.7  I would say it doesn't warrant PYTHON_RESTRICT_ABIS because it's not that the ebuild is restricted, rather dep packages are.  If they could then the ebuild could.
The only shebang to be done therefore requires only 2.7 python set active vers is redundant & python_pkg_setup is called internally by EAPI4, so pkg_setup() is not required since all works without it.
Comment 4 Alexandre Rostovtsev (RETIRED) gentoo-dev 2011-11-29 22:06:59 UTC
(In reply to comment #2)
> a long time since you made that one.  I can't figure the install, it's totally
> trashed

I saw you were asking about this on IRC, so here is a quick intro to writing gnome-related ebuilds with python.

There are basically two commonly used methods of using gnome2.eclass with python.eclass:

Method 1 (traditional, for python2-only things):

EAPI="4"
PYTHON_DEPEND="2"

inherit gnome2 python

pkg_setup() {
	python_set_active_version 2
	python_pkg_setup
}

src_prepare() {
	# disable pyc compiling
	mv py-compile py-compile.orig
	ln -s $(type -P true) py-compile

	python_convert_shebangs 2 src/foobar.py # converts "#!/usr/bin/python" and
	                                        # "#!/usr/bin/env python" to call
	                                        # python2 instead
	gnome2_src_prepare
}

pkg_postinst() {
	gnome2_pkg_postinst
	python_mod_optimize foobar # if foobar module is installed under
	                           # /usr/lib/python*; if it's installed somewhere
	                           # else, replace "foobar" with e.g.
	                           # /usr/$(get_libdir)/foobar/plugins or something
}

pkg_postrm() {
	gnome2_pkg_postrm
	python_mod_cleanup foobar # or /usr/$(get_libdir)/foobar/plugins etc.
}



Method 2 (more modern, allows you to support multiple python versions):

EAPI="4"
PYTHON_DEPEND="2:2.6 3:3.1" # if you want to support python-2.6, 2.7, and 3.2
RESTRICT_PYTHON_ABIS="2.4 2.5 3.0 *-jython"

inherit gnome2 python

pkg_setup() {
	G2CONF="${G2CONF}
		--disable-stuff
		$(use_enable wombat libwombat)"

	# python_set_active_version 2 # for python2-only packages
	python_pkg_setup
}

src_prepare() {
	# disable pyc compiling
	mv py-compile py-compile.orig
	ln -s $(type -P true) py-compile

	# python_convert_shebangs 2 src/foobar.py # for python2-only packages

	gnome2_src_prepare
	python_copy_sources
}

src_configure() {
	python_execute_function -s gnome2_src_configure
}

src_compile() {
	python_execute_function -d -s
}

src_test() {
	python_execute_function -d -s
}

src_install() {
	python_execute_function -s gnome2_src_install
}

pkg_postinst() {
	gnome2_pkg_postinst
	python_mod_optimize foobar
}

pkg_postrm() {
	gnome2_pkg_postrm
	python_mod_cleanup foobar
}
Comment 5 Alexandre Rostovtsev (RETIRED) gentoo-dev 2011-11-29 22:16:28 UTC
(In reply to comment #3)
> Created attachment 294233 [details, diff] [details, diff]
> revised ebuild patch

> +	python_convert_shebangs 2.7 "${ED}"/usr/bin/revelation

You should never set a *minor* version in python_convert_shebangs. Unless, of course, you really do want to make it impossible to use your program if/when python2.8 is released.

Simply do 'python_convert_shebangs 2 "${ED}"/usr/bin/revelation', and rely on the user to have chosen a suitable python version via eselect python.
Comment 6 Ian Delaney (RETIRED) gentoo-dev 2011-11-30 02:46:28 UTC
good one, thanks.  perhaps 
python_convert_shebangs ${PYTHON_ABI} "${ED}"/usr/bin/revelation'
which relies on the user selecting python2.7 (today) and tomorrow.
nite [I saw that the notion of python2.8 has been scrapheaped; it's not going to happen, and will be taken up in python 3.X]
Comment 7 Arfrever Frehtes Taifersar Arahesis 2011-11-30 22:25:46 UTC
(In reply to comment #5)
> (In reply to comment #3)
> > +     python_convert_shebangs 2.7 "${ED}"/usr/bin/revelation
> 
> You should never set a *minor* version in python_convert_shebangs.

It's not really true.

Minor version should be present in shebangs in:

1. Target scripts in packages supporting installation for multiple Python ABIs.
Example (/usr/bin/cython is a wrapper script. /usr/bin/cython-${PYTHON_ABI} are target scripts):
$ head -n1 /usr/bin/cython*
==> /usr/bin/cython <==
#!/usr/bin/env python

==> /usr/bin/cython-2.6 <==
#!/usr/bin/python2.6

==> /usr/bin/cython-2.7 <==
#!/usr/bin/python2.7

==> /usr/bin/cython-3.1 <==
#!/usr/bin/python3.1

==> /usr/bin/cython-3.2 <==
#!/usr/bin/python3.2

2. Scripts installed in Python site-packages directories.

3. Scripts in packages NOT supporting installation for multiple Python ABIs, which import a module installed in Python site-packages directory of only 1 Python ABI.
Example:
If active version of Python 2 was initially 2.7 and a package installs /usr/lib/python2.7/site-packages/${PN} module and /usr/bin/${PN} script and /usr/bin/${PN} script imports ${PN} module, then:
- If shebang in /usr/bin/${PN} is "#!/usr/bin/python2.7", then this script
  will work (with Python 2.7) after switching of active version of Python 2
  to 2.6.
- If shebang in /usr/bin/${PN} is "#!/usr/bin/python2", then this script
  will fail with ImportError after switching of active version of Python 2
  to 2.6.
Comment 8 Arfrever Frehtes Taifersar Arahesis 2011-11-30 22:39:12 UTC
(In reply to comment #4)
> Method 2 (more modern, allows you to support multiple python versions):
> 
> EAPI="4"
> PYTHON_DEPEND="2:2.6 3:3.1" # if you want to support python-2.6, 2.7, and 3.2
> RESTRICT_PYTHON_ABIS="2.4 2.5 3.0 *-jython"

python.eclass doesn't support Python 3.0. You should also restrict *-pypy-* in GNOME packages.

> pkg_setup() {
>     G2CONF="${G2CONF}
>         --disable-stuff
>         $(use_enable wombat libwombat)"
> 
>     # python_set_active_version 2 # for python2-only packages

python_set_active_version() cannot be used in packages supporting installation for multiple Python ABIs (even only multiple versions of CPython 2).

> src_prepare() {
>     # disable pyc compiling
>     mv py-compile py-compile.orig
>     ln -s $(type -P true) py-compile

Alternatively you can use:
echo "#!/bin/sh" > config/py-compile

> src_compile() {
>     python_execute_function -d -s

You can use a wrapper function:
python_src_compile

(If PYTHON_EXPORT_PHASE_FUNCTIONS is set during importing of python.eclass, then python_src_prepare(), python_src_configure(), python_src_compile(), python_src_test() and python_src_install() are exported.)

> src_test() {
>     python_execute_function -d -s

You can use a wrapper function:
python_src_test

> src_install() {
>     python_execute_function -s gnome2_src_install

A better way is:

installation() {
	GNOME2_DESTDIR="${T}/images/${PYTHON_ABI}/" gnome2_src_install
}
python_execute_function -s installation
python_merge_intermediate_installation_images "${T}/images"
Comment 9 Alexandre Rostovtsev (RETIRED) gentoo-dev 2011-12-26 06:26:15 UTC
(In reply to comment #8)
Thanks for the corrections! However, the following will not work:

> A better way is:
> 
> installation() {
>     GNOME2_DESTDIR="${T}/images/${PYTHON_ABI}/" gnome2_src_install
> }
> python_execute_function -s installation
> python_merge_intermediate_installation_images "${T}/images"

Unfortunately, gnome2.eclass does not support GNOME2_DESTDIR or any similar way of setting a DESTDIR different from ${D}. (Note that workarounds like gnome2_src_install DESTDIR="${T}/images/${PYTHON_ABI}/" are *not* recommended, since .la file removal, mimeinfo.cache handling etc. will fail to run if DESTDIR is not under ${D}.)
Comment 10 Arfrever Frehtes Taifersar Arahesis 2011-12-26 06:58:15 UTC
(In reply to comment #9)
> Unfortunately, gnome2.eclass does not support GNOME2_DESTDIR

Please backport changes implemented in gnome2.eclass in Progress Overlay.
Comment 11 Tristan Heaven (RETIRED) gentoo-dev 2012-05-22 16:46:47 UTC
Fixed, thanks.