Re: [gentoo-dev] [PATCH] Check for USE_PYTHON - PYTHON_TARGETS equiv.
On Tue, Nov 6, 2012 at 5:40 PM, Brian Harring ferri...@gmail.com wrote: On Tue, Nov 06, 2012 at 12:31:07PM -0500, Mike Gilbert wrote: On Mon, Nov 5, 2012 at 7:48 PM, Brian Harring ferri...@gmail.com wrote: Either way, I'm honestly not trying to piss folks off here nor stop the efforts to dig us out of the python.eclass mess. That said, *this time around* that eclass should actually have a plan so that we don't wind up in the same cluster fuck scenario as prior. It's a simple enough request; document your roadmap. Asking for reviews w/out that, frankly, is pointless (and sooner or later some asswipe like me is going to start -1'ing things till that's addressed). If anyone wants to help in drafting a GLEP, I would appreciate it. I'll try to start that this week. There will definitely be some holes, since I really don't have an all encompassing plan in my head. But it will be good to fill those in. Holes in the glep can be sorted/fleshed out; trust me, way more preferable sorting it there then in a live implementation the tree relies upon. :) Sorry to do this, but I don't think I'm ever going to get around to writing a glep. However, I'm happy to assist someone else.
Re: [gentoo-dev] [PATCH] Check for USE_PYTHON - PYTHON_TARGETS equiv.
On Tue, 6 Nov 2012 14:40:19 -0800 Brian Harring ferri...@gmail.com wrote: On Tue, Nov 06, 2012 at 12:31:07PM -0500, Mike Gilbert wrote: On Mon, Nov 5, 2012 at 7:48 PM, Brian Harring ferri...@gmail.com wrote: Either way, I'm honestly not trying to piss folks off here nor stop the efforts to dig us out of the python.eclass mess. Oh really? Well just as well you weren't actually trying. Not there is any doubt without deliberate intent. That said, *this time around* that eclass should actually have a plan so that we don't wind up in the same cluster fuck scenario as prior. Ah, ye have a way with words of the expletive kind. Pity that. It's a simple enough request; document your roadmap. Asking for reviews w/out that, frankly, is pointless er yep. point here with some merit. The steps to filling that gap are well in underway. mgorny has been busily beavering away making guides of the -r1 kind and you ought note that some have been reviewed, edited, submitted and commited to the gentoo land bank of docs. (and sooner or later some asswipe like me is going to start -1'ing things till that's addressed). eeer yep, well, what more can we say. If anyone wants to help in drafting a GLEP, I would appreciate it. I'll try to start that this week. There will definitely be some holes, since I really don't have an all encompassing plan in my head. But it will be good to fill those in. Holes in the glep can be sorted/fleshed out; trust me, way more preferable sorting it there then in a live implementation the tree relies upon. :) Thanks- ~harring not knowing Brian from any prior encounters, am pleased to make yr acquaintance. I've been following mgorny's -r1 efforts with interest from a front row seat in gentoo-python. I couldn't help but notice the metaphorical steam shooting from his ears when came the prompt to follow the plan suggested by on harring. It seems that the style of reply from one harring to this one man band (mgorny's) effort has indeed made an impact of resentment and hostility. One can only ponder as to what brought this about. That anyone has finally stepped up to make the alleged wrongs of the python.eclass is is a watershed moment in itself. To take a watershed moment and then hit it with such a volley of critique is, may I suggest, pure folley. The young man has taken on a mammoth task and it surprises me not that from time to time he discovers that he has bitten off more than he intended to chew. Dare I say, cut him some slack and a sense of gratitude for grabbing such a poisoned chalice with both hands and running with it. Remembering the ways of the python state, be they simple or complex, easily understood or macabe, ripple and reverberate through to every corner of the gentoo portage list. It's no trivial task in process. He needs support, dollups and dollups of it. He has at least a trickle at this point. -- kind regards Ian Delaney
Re: [gentoo-dev] [PATCH] Check for USE_PYTHON - PYTHON_TARGETS equiv.
Le lundi 05 novembre 2012 à 16:48 -0800, Brian Harring a écrit : Either way, I'm honestly not trying to piss folks off here nor stop the efforts to dig us out of the python.eclass mess. That said, *this time around* that eclass should actually have a plan so that we don't wind up in the same cluster fuck scenario as prior. I'm sure everyone understands that we want to avoid these eclass to be a flying spaghetti monster again. I am probably biased as I did not find using python.eclass that difficult but I must admit the new one is much easier to understand at least and for the case of distutils, really simple to use as I have packaged a handful of pypi hosted packages in less than 5 minutes each. So as a user of those eclasses and seeing the current code/patches I think I can describe a bit what is intended, although I am not part of the writing of it. python-r1.eclass is intended to provide all necessary functions to help building packages using python, be it pure-python or python bindings or however you may need python. It differs a lot from python.eclass in that in does not try to attempt to define any phase which is imho fine as that would be better done by another eclass more tied to the case being considered, autotools-python, cmake-python, but I'm hypothesizing of the use I would do of it for Gnome originated packages. python-r1.eclass also wants to make things clear for package managers by exposing the current selected python interpreter (or ABI if you prefer) as USE_EXPAND flags. As already explained in other threads, this is very similar to ruby.eclass and tentative multilib support and it appears to be working decently fine. As for the use of USE_PYTHON, I would guess that it was not reused to: * not have to deal with backward compatibility * avoid confusion wrt to USE_EXPAND behavior and result of mixing USE_PYTHON definition that are not use flags at all distutils-r1.eclass is a simple eclass using python-r1.eclass in order to build any python package relying on setuptools/distutils. Basically, you should not need to do more than: EAPI=bla PYTHON_COMPAT=( mylist ) inherit distutils-r1 and you are done. If someone wants to check how it looks like for real world examples, check for rq-* ebuilds in my dev overlay. Feel free to stab me if I telling atrocities or ask more details if that looks insufficient, I'm sure this will help draft the roadmap and/or enhance eclass documentation you'd like to see. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] [PATCH] Check for USE_PYTHON - PYTHON_TARGETS equiv.
Le mardi 06 novembre 2012 à 14:13 +0100, Gilles Dartiguelongue a écrit : [snip] Forgot to add that obviously, as already explained by Michał, distutils-r1 being (almost) the only demo out there to make use of this new eclass, most the of little things that would make it a success may still be missing because of the variety of ways python can be used in packages. I'd say these new eclasses need some more early adopters rather than reviewers (might be the same person though) to make sure it is actually usable, not just for distutils-r1. I am planning on working on this for gnome after the whole gnome-3.6/gstreamer-1 work is over. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] [PATCH] Check for USE_PYTHON - PYTHON_TARGETS equiv.
On Mon, Nov 5, 2012 at 7:48 PM, Brian Harring ferri...@gmail.com wrote: On Mon, Nov 05, 2012 at 06:54:45PM -0500, Mike Gilbert wrote: On Mon, Nov 5, 2012 at 6:34 PM, Brian Harring ferri...@gmail.com wrote: This isn't quite what I'm asking for. I want y'all to literally document thus: 1) What your finished solution is going to look like. Users control which implementations are enabled via PYTHON_TARGETS, how y'all will handle if no targets are currently specified (user hasn't made a choice), etc. 2) How you're planning on getting there- literally, how things are going to transition to your proposed replacement for python.eclass, how the use deps will be structured, the potential gaps dependencye wise as you go forward, etc. As I indicated in my email, all folks see are changes coming in, no sign of the actual end form you're intending, nor how you plan on getting there. I realize y'all may get pissed at being asked to layout your actual plans... fact is, python.eclass got into this mess since people couldn't track where it was going ultimately leading to the source being spaghetti. Lay out where y'all are going w/ this, and *how*, so people can actually comment/contribute/avoid recreating another python.eclass where no one understands it. :) I will admit right now that I don't have a master plan in mind, and we are sort of making it up as we go along. I am not a software engineer; I just like to read/hack on code. I would love for some master architect to come along and document where we are headed, but that hasn't happened. And I'm not the person to do it -- it just doesn't interest me. mgorny has been writing lots of code and is looking for someone to review it. I'm very good at answering specific questions and offering an informed opinion, so I'm attempting to do so. Just zeroing in on this since my other questions aren't really getting addressed in the fashion I want- this however is the core point. Bluntly, there needs to be a plan- and it needs to be shared w/ folk. I wasn't kidding when I stated review requires making sure your reviewer understands your change and the intent; as is, all that's realistically occurring here is mgorny gets at best a comment or two bash wise, and that's it- nothing more since no one particularly knows where this is going and we just see random patchsets w/out much explanation as to how this all plugs together. I'm not demanding a point by point plan here; I'm frankly asking that the steps/end results be shared so that we don't wind up with another python.eclass, just this time w/ mgorny being the one who's got it all in his head. It's easy enough to write up a doc (glep if you want) laying out the intent and the roadmap. This should be done- if it has been already, link it in somewhere or start referencing it so the rest of us know wtf the plan is. Simple example, I'd ask why was PYTHON_TARGETS added when USE_PYTHON could've been fixed/coopted into the same thing?. I ask that now, I'll get flak/bitchyness frankly since it's already deployed/in use. Either way, I'm honestly not trying to piss folks off here nor stop the efforts to dig us out of the python.eclass mess. That said, *this time around* that eclass should actually have a plan so that we don't wind up in the same cluster fuck scenario as prior. It's a simple enough request; document your roadmap. Asking for reviews w/out that, frankly, is pointless (and sooner or later some asswipe like me is going to start -1'ing things till that's addressed). If anyone wants to help in drafting a GLEP, I would appreciate it. I'll try to start that this week. There will definitely be some holes, since I really don't have an all encompassing plan in my head. But it will be good to fill those in.
Re: [gentoo-dev] [PATCH] Check for USE_PYTHON - PYTHON_TARGETS equiv.
On Tue, Nov 06, 2012 at 12:31:07PM -0500, Mike Gilbert wrote: On Mon, Nov 5, 2012 at 7:48 PM, Brian Harring ferri...@gmail.com wrote: Either way, I'm honestly not trying to piss folks off here nor stop the efforts to dig us out of the python.eclass mess. That said, *this time around* that eclass should actually have a plan so that we don't wind up in the same cluster fuck scenario as prior. It's a simple enough request; document your roadmap. Asking for reviews w/out that, frankly, is pointless (and sooner or later some asswipe like me is going to start -1'ing things till that's addressed). If anyone wants to help in drafting a GLEP, I would appreciate it. I'll try to start that this week. There will definitely be some holes, since I really don't have an all encompassing plan in my head. But it will be good to fill those in. Holes in the glep can be sorted/fleshed out; trust me, way more preferable sorting it there then in a live implementation the tree relies upon. :) Thanks- ~harring
[gentoo-dev] [PATCH] Check for USE_PYTHON - PYTHON_TARGETS equiv.
---
gx86/eclass/python-r1.eclass | 66
1 file changed, 66 insertions(+)
diff --git a/gx86/eclass/python-r1.eclass b/gx86/eclass/python-r1.eclass
index 0d6ef4c..6d4eb33 100644
--- a/gx86/eclass/python-r1.eclass
+++ b/gx86/eclass/python-r1.eclass
@@ -363,6 +363,70 @@ python_copy_sources() {
done
}
+# @FUNCTION: _python_check_USE_PYTHON
+# @INTERNAL
+# @DESCRIPTION:
+# Check whether USE_PYTHON and PYTHON_TARGETS are in sync. Output
+# warnings if they are not.
+_python_check_USE_PYTHON() {
+ if [[ ! ${_PYTHON_USE_PYTHON_CHECKED} ]]; then
+ _PYTHON_USE_PYTHON_CHECKED=1
+
+ local USE_PYTHON=${USE_PYTHON}
+
+ if [[ ! ${USE_PYTHON} ]]; then
+ # default to selected Python2+3
+ if has_version app-admin/eselect-python; then
+ local py2=$(eselect python show --python2)
+ local py3=$(eselect python show --python3)
+
+ USE_PYTHON=${py2#python} ${py3#python}
+ fi
+ fi
+
+ local impl warned
+ for impl in ${PYTHON_COMPAT[@]}; do
+ local abi
+ case ${impl} in
+ python*)
+ abi=${impl#python}
+ ;;
+ jython*)
+ abi=${impl#jython}-jython
+ ;;
+ pypy*)
+ abi=2.7-pypy-${impl#pypy}
+ ;;
+ *)
+ die Unexpected Python implementation:
${impl}
+ ;;
+ esac
+
+ has ${abi/_/.} ${USE_PYTHON}
+ local has_abi=${?}
+ use python_targets_${impl}
+ local has_impl=${?}
+
+ if [[ ${has_abi} != ${has_impl} ]]; then
+ if [[ ! ${warned} ]]; then
+ ewarn PYTHON_TARGETS - USE_PYTHON
inconsistency found. This may result
+ ewarn in missing modules when trying
to use Python packages. Please ensure
+ ewarn that the same implementations
are listed in both variables.
+ ewarn
+
+ warned=1
+ fi
+
+ if [[ ${has_abi} == 0 ]]; then
+ ewarn Implementation ${impl} disabled
but ${abi/_/.} in USE_PYTHON
+ else
+ ewarn Implementation ${impl} enabled
but ${abi/_/.} not in USE_PYTHON
+ fi
+ fi
+ done
+ fi
+}
+
# @FUNCTION: python_foreach_impl
# @USAGE: command [args...]
# @DESCRIPTION:
@@ -376,6 +440,8 @@ python_copy_sources() {
python_foreach_impl() {
debug-print-function ${FUNCNAME} ${@}
+ _python_check_USE_PYTHON
+
local impl
local bdir=${BUILD_DIR:-${S}}
--
1.7.12.4
Re: [gentoo-dev] [PATCH] Check for USE_PYTHON - PYTHON_TARGETS equiv.
And in case anyone wondered, the output looks like this: * PYTHON_TARGETS - USE_PYTHON inconsistency found. This may result * in missing modules when trying to use Python packages. Please ensure * that the same implementations are listed in both variables. * * Implementation python2_5 disabled but 2.5 in USE_PYTHON * Implementation python3_1 disabled but 3.1 in USE_PYTHON * Implementation jython2_5 enabled but 2.5-jython not in USE_PYTHON -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] Check for USE_PYTHON - PYTHON_TARGETS equiv.
Le lundi 05 novembre 2012 à 13:15 +0100, Michał Górny a écrit : And in case anyone wondered, the output looks like this: * PYTHON_TARGETS - USE_PYTHON inconsistency found. This may result * in missing modules when trying to use Python packages. Please ensure * that the same implementations are listed in both variables. * * Implementation python2_5 disabled but 2.5 in USE_PYTHON * Implementation python3_1 disabled but 3.1 in USE_PYTHON * Implementation jython2_5 enabled but 2.5-jython not in USE_PYTHON Shouldn't that be called in pkg_setup in relevant EAPI ? -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] [PATCH] Check for USE_PYTHON - PYTHON_TARGETS equiv.
On Mon, 05 Nov 2012 13:43:50 +0100 Gilles Dartiguelongue e...@gentoo.org wrote: Le lundi 05 novembre 2012 à 13:15 +0100, Michał Górny a écrit : And in case anyone wondered, the output looks like this: * PYTHON_TARGETS - USE_PYTHON inconsistency found. This may result * in missing modules when trying to use Python packages. Please ensure * that the same implementations are listed in both variables. * * Implementation python2_5 disabled but 2.5 in USE_PYTHON * Implementation python3_1 disabled but 3.1 in USE_PYTHON * Implementation jython2_5 enabled but 2.5-jython not in USE_PYTHON Shouldn't that be called in pkg_setup in relevant EAPI ? The eclasses don't export pkg_setup(). -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] Check for USE_PYTHON - PYTHON_TARGETS equiv.
On Mon, Nov 05, 2012 at 01:15:45PM +0100, Micha?? G??rny wrote: And in case anyone wondered, the output looks like this: * PYTHON_TARGETS - USE_PYTHON inconsistency found. This may result * in missing modules when trying to use Python packages. Please ensure * that the same implementations are listed in both variables. * * Implementation python2_5 disabled but 2.5 in USE_PYTHON * Implementation python3_1 disabled but 3.1 in USE_PYTHON * Implementation jython2_5 enabled but 2.5-jython not in USE_PYTHON If you're going to complain to users about flags being disabled in USE_PYTHON, use the actual flag name. Also... hopefully you typo'd, but 2.5-jython? Where was it decided the naming there was being shifted around? None of the code in the eclasses backs that text up from what I can tell. As floppym said; this flag isn't documented, so you're making it fairly hard to actually comment/review on what you're doing here- we just see glimpses of random patches, without knowing exactly what you intend overall. Documenting your end goal (moving people to USE_PYTHON? etc) is kind of necessary; normal rules of review reply, you want reviews, you make sure your reviewers know wtf you're trying to do and ultimately why. ~harring
Re: [gentoo-dev] [PATCH] Check for USE_PYTHON - PYTHON_TARGETS equiv.
On Mon, Nov 5, 2012 at 5:25 PM, Brian Harring ferri...@gmail.com wrote:
On Mon, Nov 05, 2012 at 01:15:45PM +0100, Micha?? G??rny wrote:
And in case anyone wondered, the output looks like this:
* PYTHON_TARGETS - USE_PYTHON inconsistency found. This may result
* in missing modules when trying to use Python packages. Please ensure
* that the same implementations are listed in both variables.
*
* Implementation python2_5 disabled but 2.5 in USE_PYTHON
* Implementation python3_1 disabled but 3.1 in USE_PYTHON
* Implementation jython2_5 enabled but 2.5-jython not in USE_PYTHON
If you're going to complain to users about flags being disabled in
USE_PYTHON, use the actual flag name.
Those are the correct flag names.
Also... hopefully you typo'd, but 2.5-jython? Where was it decided
the naming there was being shifted around? None of the code in the
eclasses backs that text up from what I can tell.
That's no typo.
2.5-jython is the PYTHON_ABI from python.eclass. It means version 2.5
of the python language as implemented by jython. The intent is to
allow for it to be matched by a glob pattern like 2.* in
RESTRICT_PYTHON_ABIS.
We have basically abandoned the PYTHON_ABI concept with the new
eclass. Instead, we have values in PYTHON_TARGETS, which match up to
an implementation and version. For example: jython2_5, for
dev-java/jython-2.5.
As floppym said; this flag isn't documented, so you're making it
fairly hard to actually comment/review on what you're doing here- we
just see glimpses of random patches, without knowing exactly what you
intend overall.
I think the scope of people who can review this is limited to those
that have some understanding of how python.eclass functions; a limited
subset indeed. ;-)
USE_PYTHON is a variable in python.eclass that python devs use to
install python packages for any arbitrary python implementation,
without using eselect python. sys-apps/portage knows nothing about it,
and your typical user doesn't do anything with it.
PYTHON_TARGETS is a similar variable that was introduced in python-r1
(python-distutils-ng actually). It is a use-expanded variable so that
portage can actually use its values for dependency resolution.
Documenting your end goal (moving people to USE_PYTHON? etc) is kind
of necessary; normal rules of review reply, you want reviews, you make
sure your reviewers know wtf you're trying to do and ultimately why.
The end goal here is to migrate ebuilds to PYTHON_TARGETS. We can't
migrate every package in the tree at once, so this check is being
proposed to ensure that the user's settings for python.eclass
(USE_PYTHON or eselect python --python{2,3}) and python-r1.eclass
(PYTHON_TARGETS use-expand) match up.
If they are out-of-sync, users may get build errors about missing
modules. For instance, if dev-python/setuptools is installed with
PYTHON_TARGETS=python2_7, but the user has python3.2 selected via
eselect, they may get an error when they try to install packages using
python.eclass if they depend on dev-python/setuptools.
As we migrate more python libraries to python-r1, we can utilize
use-deps to move this into the dependency resolver. This is something
that was not possible with the old python.eclass.
Re: [gentoo-dev] [PATCH] Check for USE_PYTHON - PYTHON_TARGETS equiv.
On Mon, Nov 05, 2012 at 05:50:24PM -0500, Mike Gilbert wrote:
On Mon, Nov 5, 2012 at 5:25 PM, Brian Harring ferri...@gmail.com wrote:
On Mon, Nov 05, 2012 at 01:15:45PM +0100, Micha?? G??rny wrote:
And in case anyone wondered, the output looks like this:
* PYTHON_TARGETS - USE_PYTHON inconsistency found. This may result
* in missing modules when trying to use Python packages. Please ensure
* that the same implementations are listed in both variables.
*
* Implementation python2_5 disabled but 2.5 in USE_PYTHON
* Implementation python3_1 disabled but 3.1 in USE_PYTHON
* Implementation jython2_5 enabled but 2.5-jython not in USE_PYTHON
If you're going to complain to users about flags being disabled in
USE_PYTHON, use the actual flag name.
Those are the correct flag names.
Use flags can't have '.' in them, so no, that's not the correct flag
name; if you're going to tell folk blah is not in USE_PYTHON, be
*accurate*- meaning dropp the /_/./ substitution.
Also... hopefully you typo'd, but 2.5-jython? Where was it decided
the naming there was being shifted around? None of the code in the
eclasses backs that text up from what I can tell.
That's no typo.
2.5-jython is the PYTHON_ABI from python.eclass. It means version 2.5
of the python language as implemented by jython. The intent is to
allow for it to be matched by a glob pattern like 2.* in
RESTRICT_PYTHON_ABIS.
I'd forgotten that python eclass has PYTHON_ABI it ordered w/ the
python version first.
As floppym said; this flag isn't documented, so you're making it
fairly hard to actually comment/review on what you're doing here- we
just see glimpses of random patches, without knowing exactly what you
intend overall.
I think the scope of people who can review this is limited to those
that have some understanding of how python.eclass functions; a limited
subset indeed. ;-)
Y'all want reviews, then you need to help your reviewers. Really is
that simple.
Plus, bluntly, nobody wants another scenario of python.eclass w/ no
one understanding it.
Meaning what y'all are trying to develop/push, has to be
documented/understood by everyone. Strongly suspect this is why there
isn't any real review occurring for these patches coming in- no one
particularly knows wtf y'all are going with this.
USE_PYTHON is a variable in python.eclass that python devs use to
install python packages for any arbitrary python implementation,
without using eselect python. sys-apps/portage knows nothing about it,
and your typical user doesn't do anything with it.
Eh, two things;
1) info_vars; portage actually does report on it for emerge --info.
If it's internal (no users should be setting it), then you should
revert your addition of it to info_vars.
2) nothing in the tree actually uses it. Literally, niadda- just a
dead code section in python.eclass hinged on the var being exported.
Raising the question of why y'all are adding error reporting for this,
and what this is supposed to sort.
Not particularly digging the fact this warning y'all want to add is
ran everytime python_foreach_impl is fired also; meaning this will
spam logs if it ever hits.
Documenting your end goal (moving people to USE_PYTHON? etc) is kind
of necessary; normal rules of review reply, you want reviews, you make
sure your reviewers know wtf you're trying to do and ultimately why.
The end goal here is to migrate ebuilds to PYTHON_TARGETS. We can't
migrate every package in the tree at once, so this check is being
proposed to ensure that the user's settings for python.eclass
(USE_PYTHON or eselect python --python{2,3}) and python-r1.eclass
(PYTHON_TARGETS use-expand) match up.
If they are out-of-sync, users may get build errors about missing
modules. For instance, if dev-python/setuptools is installed with
PYTHON_TARGETS=python2_7, but the user has python3.2 selected via
eselect, they may get an error when they try to install packages using
python.eclass if they depend on dev-python/setuptools.
As we migrate more python libraries to python-r1, we can utilize
use-deps to move this into the dependency resolver. This is something
that was not possible with the old python.eclass.
This isn't quite what I'm asking for. I want y'all to literally
document thus:
1) What your finished solution is going to look like. Users control
which implementations are enabled via PYTHON_TARGETS, how y'all will
handle if no targets are currently specified (user hasn't made a
choice), etc.
2) How you're planning on getting there- literally, how things are
going to transition to your proposed replacement for python.eclass,
how the use deps will be structured, the potential gaps dependencye
wise as you go forward, etc.
As I indicated in my email, all folks see are changes coming in, no
sign of the actual end form you're intending, nor how you plan on
getting there.
I realize y'all may get pissed at
Re: [gentoo-dev] [PATCH] Check for USE_PYTHON - PYTHON_TARGETS equiv.
On Mon, Nov 5, 2012 at 6:34 PM, Brian Harring ferri...@gmail.com wrote:
On Mon, Nov 05, 2012 at 05:50:24PM -0500, Mike Gilbert wrote:
On Mon, Nov 5, 2012 at 5:25 PM, Brian Harring ferri...@gmail.com wrote:
On Mon, Nov 05, 2012 at 01:15:45PM +0100, Micha?? G??rny wrote:
And in case anyone wondered, the output looks like this:
* PYTHON_TARGETS - USE_PYTHON inconsistency found. This may result
* in missing modules when trying to use Python packages. Please ensure
* that the same implementations are listed in both variables.
*
* Implementation python2_5 disabled but 2.5 in USE_PYTHON
* Implementation python3_1 disabled but 3.1 in USE_PYTHON
* Implementation jython2_5 enabled but 2.5-jython not in USE_PYTHON
If you're going to complain to users about flags being disabled in
USE_PYTHON, use the actual flag name.
Those are the correct flag names.
Use flags can't have '.' in them, so no, that's not the correct flag
name; if you're going to tell folk blah is not in USE_PYTHON, be
*accurate*- meaning dropp the /_/./ substitution.
USE_PYTHON does not enumerate USE flags. It contains a list of PYHTON_ABIs.
Also... hopefully you typo'd, but 2.5-jython? Where was it decided
the naming there was being shifted around? None of the code in the
eclasses backs that text up from what I can tell.
That's no typo.
2.5-jython is the PYTHON_ABI from python.eclass. It means version 2.5
of the python language as implemented by jython. The intent is to
allow for it to be matched by a glob pattern like 2.* in
RESTRICT_PYTHON_ABIS.
I'd forgotten that python eclass has PYTHON_ABI it ordered w/ the
python version first.
As floppym said; this flag isn't documented, so you're making it
fairly hard to actually comment/review on what you're doing here- we
just see glimpses of random patches, without knowing exactly what you
intend overall.
I think the scope of people who can review this is limited to those
that have some understanding of how python.eclass functions; a limited
subset indeed. ;-)
Y'all want reviews, then you need to help your reviewers. Really is
that simple.
Plus, bluntly, nobody wants another scenario of python.eclass w/ no
one understanding it.
Meaning what y'all are trying to develop/push, has to be
documented/understood by everyone. Strongly suspect this is why there
isn't any real review occurring for these patches coming in- no one
particularly knows wtf y'all are going with this.
USE_PYTHON is a variable in python.eclass that python devs use to
install python packages for any arbitrary python implementation,
without using eselect python. sys-apps/portage knows nothing about it,
and your typical user doesn't do anything with it.
Eh, two things;
1) info_vars; portage actually does report on it for emerge --info.
If it's internal (no users should be setting it), then you should
revert your addition of it to info_vars.
That's intended for use in bug reports, so members of the python team
can confirm the user's configuration. When I say it is to be used by
devs, I mean that developers and power users set it in make.conf,
not that it is set in ebuids.
2) nothing in the tree actually uses it. Literally, niadda- just a
dead code section in python.eclass hinged on the var being exported.
Raising the question of why y'all are adding error reporting for this,
and what this is supposed to sort.
Every ebuild in the tree which inherits python.eclass and sets
SUPPORT_PYTHON_ABIS utilizes USE_PYTHON if it has been set in the
environment or in make.conf. I think you misinterpreted my meaning
here.
Not particularly digging the fact this warning y'all want to add is
ran everytime python_foreach_impl is fired also; meaning this will
spam logs if it ever hits.
Documenting your end goal (moving people to USE_PYTHON? etc) is kind
of necessary; normal rules of review reply, you want reviews, you make
sure your reviewers know wtf you're trying to do and ultimately why.
The end goal here is to migrate ebuilds to PYTHON_TARGETS. We can't
migrate every package in the tree at once, so this check is being
proposed to ensure that the user's settings for python.eclass
(USE_PYTHON or eselect python --python{2,3}) and python-r1.eclass
(PYTHON_TARGETS use-expand) match up.
If they are out-of-sync, users may get build errors about missing
modules. For instance, if dev-python/setuptools is installed with
PYTHON_TARGETS=python2_7, but the user has python3.2 selected via
eselect, they may get an error when they try to install packages using
python.eclass if they depend on dev-python/setuptools.
As we migrate more python libraries to python-r1, we can utilize
use-deps to move this into the dependency resolver. This is something
that was not possible with the old python.eclass.
This isn't quite what I'm asking for. I want y'all to literally
document thus:
1) What your finished solution is going to look like.
Re: [gentoo-dev] [PATCH] Check for USE_PYTHON - PYTHON_TARGETS equiv.
On Mon, Nov 05, 2012 at 06:54:45PM -0500, Mike Gilbert wrote: On Mon, Nov 5, 2012 at 6:34 PM, Brian Harring ferri...@gmail.com wrote: This isn't quite what I'm asking for. I want y'all to literally document thus: 1) What your finished solution is going to look like. Users control which implementations are enabled via PYTHON_TARGETS, how y'all will handle if no targets are currently specified (user hasn't made a choice), etc. 2) How you're planning on getting there- literally, how things are going to transition to your proposed replacement for python.eclass, how the use deps will be structured, the potential gaps dependencye wise as you go forward, etc. As I indicated in my email, all folks see are changes coming in, no sign of the actual end form you're intending, nor how you plan on getting there. I realize y'all may get pissed at being asked to layout your actual plans... fact is, python.eclass got into this mess since people couldn't track where it was going ultimately leading to the source being spaghetti. Lay out where y'all are going w/ this, and *how*, so people can actually comment/contribute/avoid recreating another python.eclass where no one understands it. :) I will admit right now that I don't have a master plan in mind, and we are sort of making it up as we go along. I am not a software engineer; I just like to read/hack on code. I would love for some master architect to come along and document where we are headed, but that hasn't happened. And I'm not the person to do it -- it just doesn't interest me. mgorny has been writing lots of code and is looking for someone to review it. I'm very good at answering specific questions and offering an informed opinion, so I'm attempting to do so. Just zeroing in on this since my other questions aren't really getting addressed in the fashion I want- this however is the core point. Bluntly, there needs to be a plan- and it needs to be shared w/ folk. I wasn't kidding when I stated review requires making sure your reviewer understands your change and the intent; as is, all that's realistically occurring here is mgorny gets at best a comment or two bash wise, and that's it- nothing more since no one particularly knows where this is going and we just see random patchsets w/out much explanation as to how this all plugs together. I'm not demanding a point by point plan here; I'm frankly asking that the steps/end results be shared so that we don't wind up with another python.eclass, just this time w/ mgorny being the one who's got it all in his head. It's easy enough to write up a doc (glep if you want) laying out the intent and the roadmap. This should be done- if it has been already, link it in somewhere or start referencing it so the rest of us know wtf the plan is. Simple example, I'd ask why was PYTHON_TARGETS added when USE_PYTHON could've been fixed/coopted into the same thing?. I ask that now, I'll get flak/bitchyness frankly since it's already deployed/in use. Either way, I'm honestly not trying to piss folks off here nor stop the efforts to dig us out of the python.eclass mess. That said, *this time around* that eclass should actually have a plan so that we don't wind up in the same cluster fuck scenario as prior. It's a simple enough request; document your roadmap. Asking for reviews w/out that, frankly, is pointless (and sooner or later some asswipe like me is going to start -1'ing things till that's addressed). ~harring
