Re: [gentoo-python] [PATCH] Error out if something installs the 'tests' package.

[IAN DELANEY <della5@iinet.com.au>]

On Sun,  3 Feb 2013 11:19:24 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> This is a common error, especially in my ebuilds or those based on
> mine. It gives a bunch of collisions, so dying here seems to be
> acceptable while eqawarn is easy to miss.
> ---
>  gx86/eclass/distutils-r1.eclass | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/gx86/eclass/distutils-r1.eclass
> b/gx86/eclass/distutils-r1.eclass index 27730f5..13d65b5 100644
> --- a/gx86/eclass/distutils-r1.eclass
> +++ b/gx86/eclass/distutils-r1.eclass
> @@ -367,6 +367,10 @@ distutils-r1_python_install() {
>  
>  	esetup.py install "${flags[@]}" --root="${root}" "${@}"
>  
> +	if [[ -d ${root}$(python_get_sitedir)/tests ]]; then
> +		die "Package installs 'tests' package, file
> collisions likely."
> +	fi
> +
>  	if [[ ! ${DISTUTILS_SINGLE_IMPL} ]]; then
>  		_distutils-r1_rename_scripts "${root}"
>  		_distutils-r1_merge_root "${root}" "${D}"

Actually I don't like it.  I did a 'fix' like this to a package in a
more rare instance concerning building of docs, but the Rx was to
abort and call die and tell the user to start again.  The chief critic
of this concluded I didn't know what I was doing, but then he's known
for his prolific and indiscriminant use of hyperbole.  The 'better'
solution was to indeed to correct the underlying flaw and and get on
with emerging the package. The practice of 'abort and start again' is,
I admit, unsavoury at best. 

Given that this is a relatively common error, let's get a 'clear
picture' of the status of the presence of the relatively common
instance test folders and suites in python packages.  There are some
that install them and some that don't, so we're forced to chase a
'moving target'. Can we decide categorically that test suites need and
ought not be installed in python packages, or do we have to water it
down with "Oh it depends on these dozens of possibilities  and those
ones over there"?  This creates a myriad of scenarios of uncertainty.

Step 1.  Make the target still

Step 2.  Once the target is still, then deal with it accordingly;
install them in a collision free fashion, or delete them once and for
all if we can declare then un-needed.  The latter has quite a bit going
for it.

Step 3.  Make potential critics like the anonymous dev previously and
obliquely cited forever silent, and get on with emerging the package. 

-- 
kind regards

Ian Delaney