[gentoo-dev] Re: [gentoo-python] New eclass for Python

[Mike Gilbert <floppym@gentoo.org>]

On Tue, Feb 28, 2012 at 4:13 PM, Krzysztof Pawlik <nelchael@gentoo.org> wrote:
> Hello,
>
> After some work during weekend on Python packages I've decided to start a
> rewrite of Python/distutils eclass for installing Python packages. My main goal
> was simplicity and functionality similar to ruby-ng.eclass (thanks Ruby team for
> your great work!). Python team members already contributed comments and
> suggestions and helped me to make the eclass better, thank you!
>
> Highlights:
>  - *SIMPLE*next
>  - uses PYTHON_TARGETS use-expand (no more python-updater, whoooo!)
>  - EAPI4 required, uses REQUIRED_USE
>  - <400 lines of code including documentation
>  - should work for >95% of packages (my educated guess)
>  - did I mention it's *SIMPLE*?
>  - easy to maintain & read so it's also easy to use
>
> Important thing: I'm not aiming at having 100% functionality of current
> python.eclass+distutils.eclass in the new one, I think that simplicity is more
> important that supporting every possible, obscure case that's out there.
>
> I'm attaching the eclass itself and two ebuilds using it, code is also available
> in my overlay at http://git.overlays.gentoo.org/gitweb/?p=dev/nelchael.git;a=summary
>
> If there are no objections then during the weekend (March 3, 4) I will add this
> to portage (after finishing remaining TODO items, PyPy requires 4G of RAM(!!)).
>
> --
> Krzysztof Pawlik  <nelchael at gentoo.org>  key id: 0xF6A80E46
> desktop-misc, java, vim, kernel, python, apache...
>

# Phase function: src_unpack
python-distutils-ng_src_unpack() {
	[[ "${PYTHON_OPTIONAL}" = "yes" ]] && { use python || return; }

	if type python_unpack &> /dev/null; then
		# This should not run anything specific to any single Python
		# implementation, keep it generic:
		python_unpack_all
	else
		[[ -n ${A} ]] && unpack ${A}
	fi
}

I think you meant to write "if type python_unpack_all".

More to the point, I don't actually understand why this function
exists. It doesn't actually do anything that default_src_unpack does
not do already. Exporting it will clobber any vcs eclasses if the
inherit order is wrong.