On Wed, 2021-08-11 at 09:49 +0200, Michał Górny wrote:
> It is a de-facto standard to use deselect=() and/or ignore=() arrays
> to pass arguments to epytest.  Let's make the function take them
> automatically without requiring unsafe hacks such as:
> 
>     epytest ${deselect[@]/#/--deselect }
> 
> Signed-off-by: Michał Górny <[email protected]>
> ---
>  eclass/python-utils-r1.eclass | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
> index b104b6694ac3..04b82d4f7a78 100644
> --- a/eclass/python-utils-r1.eclass
> +++ b/eclass/python-utils-r1.eclass
> @@ -1250,6 +1250,10 @@ build_sphinx() {
>  # Run pytest, passing the standard set of pytest options, followed
>  # by user-specified options.
>  #
> +# If 'deselect' array is present in the calling scope, all its elements
> +# are added as --deselect arguments to pytest.  If 'ignore' array
> +# is present, its elements are added as --ignore arguments.
> +#
>  # This command dies on failure and respects nonfatal.
>  epytest() {
>       debug-print-function ${FUNCNAME} "${@}"
> @@ -1268,6 +1272,13 @@ epytest() {
>               # for end users, as it tends to fail on new warnings from deps
>               -Wdefault
>       )
> +     local x
> +     for x in "${deselect[@]}"; do
> +             args+=( --deselect "${x}" )
> +     done
> +     for x in "${ignore[@]}"; do
> +             args+=( --ignore "${x}" )
> +     done
>       set -- "${EPYTHON}" -m pytest "${args[@]}" "${@}"
>  
>       echo "${@}" >&2

Arthur Zamarin did some grepping and found that there are ebuilds that
are actually broken by this change.  For example, in one ebuild some
mgorny did:

  deselect=( --ignore ... )

I suppose we have two main options right now:

1. Use more unique names for the new variables.  Possibly make them
uppercase and supported without redefining python_test(), e.g.:

  distutils_enable_tests pytest

  EPYTEST_DESELECT=(
    tests/some_broken_stuff.py::test_fnord
  )

2. Pre-fix the ebuilds and go as-is.  I kinda dislike this because it
assumes custom repos could get hit by this, and requires us to find all
potentially broken occurences.

-- 
Best regards,
Michał Górny



Reply via email to