Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: avoid nested ebegin calls

2022-07-11 Thread Michał Górny
On Mon, 2022-07-11 at 07:36 -0400, Mike Gilbert wrote:
> On Mon, Jul 11, 2022 at 3:04 AM Michał Górny  wrote:
> > 
> > On Sun, 2022-07-10 at 23:53 -0400, Mike Gilbert wrote:
> > > It's common for python_check_deps to call python_has_version, which
> > > calls ebegin itself.
> > > 
> > > Signed-off-by: Mike Gilbert 
> > > ---
> > >  eclass/python-utils-r1.eclass | 3 +--
> > >  1 file changed, 1 insertion(+), 2 deletions(-)
> > > 
> > > diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
> > > index a18ca58475f..acfa83d5e18 100644
> > > --- a/eclass/python-utils-r1.eclass
> > > +++ b/eclass/python-utils-r1.eclass
> > > @@ -1399,9 +1399,8 @@ _python_run_check_deps() {
> > > 
> > >   local PYTHON_USEDEP="python_targets_${impl}(-)"
> > >   local PYTHON_SINGLE_USEDEP="python_single_target_${impl}(-)"
> > > - ebegin "  python_check_deps"
> > > + einfo "  python_check_deps"
> > >   python_check_deps
> > > - eend ${?}
> > >  }
> > > 
> > >  # @FUNCTION: python_has_version
> > 
> > What's the harm in nesting them?
> 
> It results in strange looking output, and triggers a QA warning in the
> latest version of Portage.

This change means that if python_check_deps() isn't verbose and returns
false, we have no output that it failed.  At least make it print
the result verbosely then.

-- 
Best regards,
Michał Górny




Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: avoid nested ebegin calls

2022-07-11 Thread Mike Gilbert
On Mon, Jul 11, 2022 at 3:04 AM Michał Górny  wrote:
>
> On Sun, 2022-07-10 at 23:53 -0400, Mike Gilbert wrote:
> > It's common for python_check_deps to call python_has_version, which
> > calls ebegin itself.
> >
> > Signed-off-by: Mike Gilbert 
> > ---
> >  eclass/python-utils-r1.eclass | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
> > index a18ca58475f..acfa83d5e18 100644
> > --- a/eclass/python-utils-r1.eclass
> > +++ b/eclass/python-utils-r1.eclass
> > @@ -1399,9 +1399,8 @@ _python_run_check_deps() {
> >
> >   local PYTHON_USEDEP="python_targets_${impl}(-)"
> >   local PYTHON_SINGLE_USEDEP="python_single_target_${impl}(-)"
> > - ebegin "  python_check_deps"
> > + einfo "  python_check_deps"
> >   python_check_deps
> > - eend ${?}
> >  }
> >
> >  # @FUNCTION: python_has_version
>
> What's the harm in nesting them?

It results in strange looking output, and triggers a QA warning in the
latest version of Portage.



Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: avoid nested ebegin calls

2022-07-11 Thread Michał Górny
On Sun, 2022-07-10 at 23:53 -0400, Mike Gilbert wrote:
> It's common for python_check_deps to call python_has_version, which
> calls ebegin itself.
> 
> Signed-off-by: Mike Gilbert 
> ---
>  eclass/python-utils-r1.eclass | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
> index a18ca58475f..acfa83d5e18 100644
> --- a/eclass/python-utils-r1.eclass
> +++ b/eclass/python-utils-r1.eclass
> @@ -1399,9 +1399,8 @@ _python_run_check_deps() {
>  
>   local PYTHON_USEDEP="python_targets_${impl}(-)"
>   local PYTHON_SINGLE_USEDEP="python_single_target_${impl}(-)"
> - ebegin "  python_check_deps"
> + einfo "  python_check_deps"
>   python_check_deps
> - eend ${?}
>  }
>  
>  # @FUNCTION: python_has_version

What's the harm in nesting them?

-- 
Best regards,
Michał Górny