RFC: python-distutils-ng.eclass - add a convenience variable for use deps
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hey all:

So one of the advantages of using python-distutils-ng.eclass for
building (and building against) python modules is that python module
dependencies can be guaranteed against the same python targets as what
you're building for, via the PYTHON_TARGETS use expansion.

Unfortunately, one of the drawbacks to this is that dependencies are
long and ugly.

Since in most cases, any python module in *DEPEND is going to have
python_targets_*? use deps for each implementation in $PYTHON_COMPAT,
a helper variable that can be substituted for this list would simplify
the ebuild.

The implementation in the patch below is probably not the best, but I
propose it as a starting point.


- --- python-distutils-ng.eclass 2012-06-18 10:53:33.000000000 -0400
+++ python-distutils-ng.eclass.new 2012-09-06 13:47:28.000000000
- -0400
@@ -59,6 +59,22 @@
# Set to any value to disable automatic reinstallation of scripts in
# bin directories. See python-distutils-ng_src_install function.

+# @ECLASS-VARIABLE: PTUD
+# @INTERNAL
+# @DESCRIPTION:
+# Provides the complete expansion of python_target_ use depedencies
+# from the content of $PYTHON_COMPAT ; it can be used as a shortform
+# to set or or append the use deps of complete python-module
+# dependencies, ie: RDEPEND="dev-python/foo[${PTUD}]"
+
+mysep=
+PTUD=
+for impl in ${PYTHON_COMPAT} ; do
+ PTUD+="${mysep}python_targets_${impl}?"
+ mysep=","
+done
+unset mysep
+
EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test [Snip!]

case "${EAPI}" in
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBI6eAACgkQ2ugaI38ACPB4AgD5AbdrjfoQsn 3Gf9eJSIOp7qQC
Ceu/TAaE8a+rDYoIG8QA/ivAVdNOBnzWi/VthlgkrXpkk1sQYV5hFWGcI2gVhygv
=cHPI
-----END PGP SIGNATURE-----

RFC: python-distutils-ng.eclass - add a convenience variable for use deps
 

On Thu, 06 Sep 2012 14:22:24 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> So one of the advantages of using python-distutils-ng.eclass for
> building (and building against) python modules is that python module
> dependencies can be guaranteed against the same python targets as what
> you're building for, via the PYTHON_TARGETS use expansion.
>
> Unfortunately, one of the drawbacks to this is that dependencies are
> long and ugly.
>
> Since in most cases, any python module in *DEPEND is going to have
> python_targets_*? use deps for each implementation in $PYTHON_COMPAT,
> a helper variable that can be substituted for this list would simplify
> the ebuild.

Didn't I think of the same thing some time ago?

> The implementation in the patch below is probably not the best, but I
> propose it as a starting point.
>
>
> - --- python-distutils-ng.eclass 2012-06-18 10:53:33.000000000 -0400
> +++ python-distutils-ng.eclass.new 2012-09-06 13:47:28.000000000
> - -0400
> @@ -59,6 +59,22 @@
> # Set to any value to disable automatic reinstallation of scripts in
> # bin directories. See python-distutils-ng_src_install function.
>
> +# @ECLASS-VARIABLE: PTUD

PTUD? Sounds like a verb. Something like 'you should PTUD yourself' ;D.

Not that I'm that brilliant to come up with something good but it
should start with 'PYTHON_', I think, and be explanatory.

> +# @INTERNAL
> +# @DESCRIPTION:
> +# Provides the complete expansion of python_target_ use depedencies
> +# from the content of $PYTHON_COMPAT ; it can be used as a shortform
> +# to set or or append the use deps of complete python-module
> +# dependencies, ie: RDEPEND="dev-python/foo[${PTUD}]"

I think it should spell clearer how the string looks like, i.e. that it
is 'pythonx_y?,pythonx_z?,...'.

> +
> +mysep=
> +PTUD=
> +for impl in ${PYTHON_COMPAT} ; do
> + PTUD+="${mysep}python_targets_${impl}?"
> + mysep=","
> +done
> +unset mysep
> +

Nice hack with that mysep but I don't like it, sorry. I'd rather avoid
temporary variables here, or use a function and a 'local' variable.
Calling a function in global scope shouldn't be that bad.

or just something like:

PTUD=${PYTHON_COMPAT// /?,}?

But then you would have to 'clean up' PYTHON_COMPAT first to avoid
non-space whitespace and so on.

> EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test
> [Snip!]
>
> case "${EAPI}" in

Er, that thing should go after EAPI check.

--
Best regards,
Michał Górny

RFC: python-distutils-ng.eclass - add a convenience variable for use deps
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 06/09/12 04:26 PM, Michał Górny wrote:
> On Thu, 06 Sep 2012 14:22:24 -0400 Ian Stakenvicius
> <axs@gentoo.org> wrote:
>
>> So one of the advantages of using python-distutils-ng.eclass for
>> building (and building against) python modules is that python
>> module dependencies can be guaranteed against the same python
>> targets as what you're building for, via the PYTHON_TARGETS use
>> expansion.
>>
>> Unfortunately, one of the drawbacks to this is that dependencies
>> are long and ugly.
>>
>> Since in most cases, any python module in *DEPEND is going to
>> have python_targets_*? use deps for each implementation in
>> $PYTHON_COMPAT, a helper variable that can be substituted for
>> this list would simplify the ebuild.
>
> Didn't I think of the same thing some time ago?
>

Not sure; you think of so many different things.. :D


>> The implementation in the patch below is probably not the best,
>> but I propose it as a starting point.
>>
>>
>> - --- python-distutils-ng.eclass 2012-06-18 10:53:33.000000000
>> -0400 +++ python-distutils-ng.eclass.new 2012-09-06
>> 13:47:28.000000000 - -0400 @@ -59,6 +59,22 @@ # Set to any value
>> to disable automatic reinstallation of scripts in # bin
>> directories. See python-distutils-ng_src_install function.
>>
>> +# @ECLASS-VARIABLE: PTUD
>
> PTUD? Sounds like a verb. Something like 'you should PTUD yourself'
> ;D.
>
> Not that I'm that brilliant to come up with something good but it
> should start with 'PYTHON_', I think, and be explanatory.
>

I wanted it to be short -- this is a convenience variable to be used
in *DEPEND; and since it contains Python Target Use Dependencies, i
figured the acronym was the best way to go..

PS, '@INTERNAL' is probably not a good tag to set here but i couldn't
find documentation on what tags were available; if there's a @READONLY
or @CONSTANT that would be best.

>> +# @INTERNAL +# @DESCRIPTION: +# Provides the complete expansion
>> of python_target_ use depedencies +# from the content of
>> $PYTHON_COMPAT ; it can be used as a shortform +# to set or or
>> append the use deps of complete python-module +# dependencies,
>> ie: RDEPEND="dev-python/foo[${PTUD}]"
>
> I think it should spell clearer how the string looks like, i.e.
> that it is 'pythonx_y?,pythonx_z?,...'.
>
>> + +mysep= +PTUD= +for impl in ${PYTHON_COMPAT} ; do +
>> PTUD+="${mysep}python_targets_${impl}?" + mysep="," +done +unset
>> mysep +
>
> Nice hack with that mysep but I don't like it, sorry. I'd rather
> avoid temporary variables here, or use a function and a 'local'
> variable. Calling a function in global scope shouldn't be that
> bad.
>
> or just something like:
>
> PTUD=${PYTHON_COMPAT// /?,}?
>

The 'for impl in ${PYTHON_COMPAT}' loop is actually run in global
scope later, to set *DEPEND on each python implementation; i haven't
checked but it's possible it can be done there. Also, other bits are
already using temp variables in global scope. Also2, since this var
needs to be substituted directly into atoms of the ebuild's *DEPEND,
imo it needs to be in global scope as well


> But then you would have to 'clean up' PYTHON_COMPAT first to avoid
> non-space whitespace and so on.
>
>> EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test
>> [Snip!]
>>
>> case "${EAPI}" in
>
> Er, that thing should go after EAPI check.
>


Could be, yes. I had thought to set it before the check as
PYTHON_COMPAT itself is assigned (if unset) before the check.
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBJCTUACgkQ2ugaI38ACPD3TwEAj1rtDO1Rpb mf0g+nU+oHTj5Y
HIFVsn+bzbx+CB1xU5QBAKxXx5p33y4dhk03zM1VjRWM5J9QdC/uDGq42yapnfdd
=hm2B
- -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBJCrMACgkQ2ugaI38ACPAKsQD/VirFeTqL+ZdbGq0lgD8HuuyG
0YrQGw0i8CYN5eMdtpIBAIszTewkBVF75lWGull7MmWYfZkyYR PUI/b6JNnUO/o6
=fQvj
-----END PGP SIGNATURE-----

RFC: python-distutils-ng.eclass - add a convenience variable for use deps
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 06/09/12 04:26 PM, Michał Górny wrote:


Not sure; you think of so many different things.. :D




I wanted it to be short -- this is a convenience variable to be used
in *DEPEND; and since it contains Python Target Use Dependencies, i
figured the acronym was the best way to go..

PS, '@INTERNAL' is probably not a good tag to set here but i couldn't
find documentation on what tags were available; if there's a @READONLY
or @CONSTANT that would be best.



The 'for impl in ${PYTHON_COMPAT}' loop is actually run in global
scope later, to set *DEPEND on each python implementation; i haven't
checked but it's possible it can be done there. Also, other bits are
already using temp variables in global scope. Also2, since this var
needs to be substituted directly into atoms of the ebuild's *DEPEND,
imo it needs to be in global scope as well





Could be, yes. I had thought to set it before the check as
PYTHON_COMPAT itself is assigned (if unset) before the check.
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBJCTUACgkQ2ugaI38ACPD3TwEAj1rtDO1Rpb mf0g+nU+oHTj5Y
HIFVsn+bzbx+CB1xU5QBAKxXx5p33y4dhk03zM1VjRWM5J9QdC/uDGq42yapnfdd
=hm2B
- -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBJCrMACgkQ2ugaI38ACPAZjwD+PsGxG64rhK M5vmSO+g9Gc1Ij
N62tR4dar4zGlIGwwfUA/0JH62LPRO/sv6BsvAHWRfXuuU4tkYotY2m7yx5LF6sH
=Ff8b
-----END PGP SIGNATURE-----

RFC: python-distutils-ng.eclass - add a convenience variable for use deps
 

On Thu, 06 Sep 2012 16:42:27 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> - -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256

One signature is enough :P.

> On 06/09/12 04:26 PM, Michał Górny wrote:
> > Not that I'm that brilliant to come up with something good but it
> > should start with 'PYTHON_', I think, and be explanatory.
>
> I wanted it to be short -- this is a convenience variable to be used
> in *DEPEND; and since it contains Python Target Use Dependencies, i
> figured the acronym was the best way to go..
>
> PS, '@INTERNAL' is probably not a good tag to set here but i couldn't
> find documentation on what tags were available; if there's a @READONLY
> or @CONSTANT that would be best.

Try looking at the awk script in eclass-manpages/files.

> >> + +mysep= +PTUD= +for impl in ${PYTHON_COMPAT} ; do +
> >> PTUD+="${mysep}python_targets_${impl}?" + mysep="," +done +unset
> >> mysep +
> >
> > Nice hack with that mysep but I don't like it, sorry. I'd rather
> > avoid temporary variables here, or use a function and a 'local'
> > variable. Calling a function in global scope shouldn't be that
> > bad.
> >
> > or just something like:
> >
> > PTUD=${PYTHON_COMPAT// /?,}?
> >
>
> The 'for impl in ${PYTHON_COMPAT}' loop is actually run in global
> scope later, to set *DEPEND on each python implementation; i haven't
> checked but it's possible it can be done there.

Yes, that's a good idea to join loops. Bash is not a C compiler, he
won't do that for ya.

> Also, other bits are already using temp variables in global scope.

And others are also using facebook. Does that mean you really should be
like them?

> Also2, since this var needs to be substituted directly into atoms of
> the ebuild's *DEPEND, imo it needs to be in global scope as well

The variable yes, the mysep doesn't.

> > But then you would have to 'clean up' PYTHON_COMPAT first to avoid
> > non-space whitespace and so on.
> >
> >> EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test
> >> [Snip!]
> >>
> >> case "${EAPI}" in
> >
> > Er, that thing should go after EAPI check.
> >
>
> Could be, yes. I had thought to set it before the check as
> PYTHON_COMPAT itself is assigned (if unset) before the check.

Then it should be moved.

--
Best regards,
Michał Górny