• [gentoo-dev] [PATCH 1/2] distutils-r1.eclass: disable setuptools valida

    From Eli Schwartz@21:1/5 to All on Tue Nov 12 18:30:01 2024
    Trove classifiers, and their officialness, have no effect on a wheel
    other than determining whether they are allowed to be uploaded to a
    non-Gentoo website, and enabling the search index of that other site.

    We don't need this, and we don't need to validate it. Setuptools will
    disable validation if both of:

    - network downloads failed

    - cannot successfully import the `trove_classifiers` module

    occurs. If trove-classifiers is installed by coincidence, this breaks
    builds when it doesn't get updated on an extremely rapid basis and some
    random package in dev-python/* uses a classifier that was made official
    just the other day.

    We could solve this another way, by making dev-python/setuptools
    PDEPEND on trove-classifiers, and constantly bump the >= dependency. But
    this is a pointless hassle. In fact, we're actually doing it, and it's
    been a pointless hassle. We need to maintain up-to-the-minute minimum
    bounds on the very latest version, and bump setuptools to a new -rX just
    to update the minimum version of a package it doesn't even depend on. We
    need to package new versions of trove-classifiers before *other* Gentoo
    Devs outside of the python project, can successfully revbump their own packages. We need to coordinate stabilization of trove-classifiers in combination with those other packages. We force people to install a
    pointless package. We overuse PDEPEND.

    Instead, prevent the module from being successfully imported if the
    package being built, doesn't actually depend on it. Then we don't
    actually need it to be installed, and all is well. This can be done at
    the small cost of installing a fake "trove_classifiers" module and
    mutating PYTHONPATH. It is inelegant and meh, but upstream has stated
    that they will not implement a real fix.

    Bug: https://github.com/pypa/setuptools/issues/4459
    Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
    ---
    eclass/distutils-r1.eclass | 11 +++++++++++
    1 file changed, 11 insertions(+)

    diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
    index 7ab8dcae3265..9b9ba4b803ac 100644
    --- a/eclass/distutils-r1.eclass
    +++ b/eclass/distutils-r1.eclass
    @@ -1360,6 +1360,17 @@ distutils_pep517_install() {
    EOF
    )
    fi
    + if [[ ${BDEPEND} != *dev-python/trove-classifiers* ]]; then
    + # setuptools will try to import this package, if it is installed,
    + # and run validations we don't need or want that depend on
    + # having the most recent trove_classifiers version installed.
    + #
    + # https://github.com/pypa/setuptools/issues/4459
    + cat >> "${T}/trove_classifiers.py" <<-EOF || die
    + raise ImportError("hide real trove_classifiers")
    + EOF
    + local -x PYTHONPATH="${T}${PYTHONPATH+:${PYTHONPATH}}"
    + fi
    ;;
    sip)
    if [[ -n ${DISTUTILS_ARGS[@]} ]]; then
    --
    2.45.2

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=@21:1/5 to Eli Schwartz on Tue Nov 12 19:40:01 2024
    On Tue, 2024-11-12 at 12:21 -0500, Eli Schwartz wrote:
    Trove classifiers, and their officialness, have no effect on a wheel
    other than determining whether they are allowed to be uploaded to a non-Gentoo website, and enabling the search index of that other site.

    We don't need this, and we don't need to validate it. Setuptools will
    disable validation if both of:

    - network downloads failed

    - cannot successfully import the `trove_classifiers` module

    occurs. If trove-classifiers is installed by coincidence, this breaks
    builds when it doesn't get updated on an extremely rapid basis and some random package in dev-python/* uses a classifier that was made official
    just the other day.

    We could solve this another way, by making dev-python/setuptools
    PDEPEND on trove-classifiers, and constantly bump the >= dependency. But
    this is a pointless hassle. In fact, we're actually doing it, and it's
    been a pointless hassle. We need to maintain up-to-the-minute minimum
    bounds on the very latest version, and bump setuptools to a new -rX just
    to update the minimum version of a package it doesn't even depend on. We
    need to package new versions of trove-classifiers before *other* Gentoo
    Devs outside of the python project, can successfully revbump their own packages. We need to coordinate stabilization of trove-classifiers in combination with those other packages. We force people to install a
    pointless package. We overuse PDEPEND.

    Instead, prevent the module from being successfully imported if the
    package being built, doesn't actually depend on it. Then we don't
    actually need it to be installed, and all is well. This can be done at
    the small cost of installing a fake "trove_classifiers" module and
    mutating PYTHONPATH. It is inelegant and meh, but upstream has stated
    that they will not implement a real fix.

    Bug: https://github.com/pypa/setuptools/issues/4459
    Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
    ---
    eclass/distutils-r1.eclass | 11 +++++++++++
    1 file changed, 11 insertions(+)

    diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
    index 7ab8dcae3265..9b9ba4b803ac 100644
    --- a/eclass/distutils-r1.eclass
    +++ b/eclass/distutils-r1.eclass
    @@ -1360,6 +1360,17 @@ distutils_pep517_install() {
    EOF
    )
    fi
    + if [[ ${BDEPEND} != *dev-python/trove-classifiers* ]]; then

    It's not valid to access stacked variables like BDEPEND from ebuilds.

    --
    Best regards,
    Michał Górny


    -----BEGIN PGP SIGNATURE-----

    iQFGBAABCgAwFiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAmczoIQSHG1nb3JueUBn ZW50b28ub3JnAAoJEGOa2uIyniQOPZgIAM6+o6/KMZmcRe8cMrVt8MiiHieT8kJm LtKfXQcfA8NnPl/HEtDvS0uLxeswazm6b0Ms70ju5WPP61CjhGzICiXtvLu0yyUJ gAcQ/MwRYMf/FaBgLtI/p3J7nclVySo0j8s6EJc46ie43ydO9cPp+NYKB4psdGlj z77MbfsvgVqVBn8u3PKPM5SAGmlwvsCY5I5V/FiBOTjj/ZcqknjX5srJEXgnV74o 3QO6a9EppX+nKZp7ee6X0GPEwv4d92G+aFn0iI2Pvlp0+j7IGrW0DZDEmz0Wpudv RxmVAnDJSZafJX7LC3mwiyPfgkzjM/CBKK9zpb3MtSYIDoyyIUMolBs=
    =2KSF
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eli Schwartz@21:1/5 to All on Tue Nov 12 21:10:02 2024
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------T68hXqBCgaeTIZ5fWNjOaNmh
    Content-Type: text/plain; charset=UTF-8
    Content-Transfer-Encoding: quoted-printable

    On 11/12/24 1:37 PM, Michał Górny wrote:
    diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
    index 7ab8dcae3265..9b9ba4b803ac 100644
    --- a/eclass/distutils-r1.eclass
    +++ b/eclass/distutils-r1.eclass
    @@ -1360,6 +1360,17 @@ distutils_pep517_install() {
    EOF
    )
    fi
    + if [[ ${BDEPEND} != *dev-python/trove-classifiers* ]]; then

    It's not valid to access stacked variables like BDEPEND from ebuilds.


    For what reason is it invalid? Is it about whether this will work
    correctly or is there a policy reason banning it or... ?


    Note that this happens inside of a phase function, not at global scope.
    So the value of the variable is determined by the contents of the
    environment file, not from the incremental value when sourcing the
    eclass at global scope.


    --
    Eli Schwartz

    --------------T68hXqBCgaeTIZ5fWNjOaNmh--

    -----BEGIN PGP SIGNATURE-----

    wnsEABYIACMWIQTnFNnmK0TPZHnXm3qEp9ErcA0vVwUCZzOz3AUDAAAAAAAKCRCEp9ErcA0vVxEh AQCMKGTv61njN45nYpuT9xrzCb1inszOUVt8ergUnI7TJwD9HXUs5jllqsZaXs9NLQo3S5PGq4xT YWzFX9/Mk/XMvwk=
    =2w34
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=@21:1/5 to Eli Schwartz on Tue Nov 12 21:10:02 2024
    On Tue, 2024-11-12 at 15:00 -0500, Eli Schwartz wrote:
    On 11/12/24 1:37 PM, Michał Górny wrote:
    diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass index 7ab8dcae3265..9b9ba4b803ac 100644
    --- a/eclass/distutils-r1.eclass
    +++ b/eclass/distutils-r1.eclass
    @@ -1360,6 +1360,17 @@ distutils_pep517_install() {
    EOF
    )
    fi
    + if [[ ${BDEPEND} != *dev-python/trove-classifiers* ]]; then

    It's not valid to access stacked variables like BDEPEND from ebuilds.


    For what reason is it invalid? Is it about whether this will work
    correctly or is there a policy reason banning it or... ?

    Both.

    e that this happens inside of a phase function, not at global scope.
    So the value of the variable is determined by the contents of the
    environment file, not from the incremental value when sourcing the
    eclass at global scope.


    Precisely. The spec doesn't guarantee that PM will reexport
    the merged BDEPEND back into ebuild env, rather than leaving whatever
    the last eclass sourced set.

    --
    Best regards,
    Michał Górny


    -----BEGIN PGP SIGNATURE-----

    iQFGBAABCgAwFiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAmcztgoSHG1nb3JueUBn ZW50b28ub3JnAAoJEGOa2uIyniQOFEIIAIjZ6I/pOcw9Co0smB1OyRZJY512SmB0 61OFslGz7ltOl/Tk3/LhbAHTgawe7xuc9JY3QVsU9/A12wLzyr+9rQT8z1j+DzV7 rFNSTWLe6Oyx03UKucMQeZftEgiDJ0b/JdinNLChjed9JVzh64QHIe3SU6MbWJjX bYqWarKaW3VVlZwk2MP5SPJfCL5cNdQkqdikxyehNE0VC6k7z4eQuARFriU0xEdF pCZPNhEuuk1xFrHIxhemAa+o+K2VFWqmtLikkzV8QXbh4YW5sAZISaKvD+b8Ge8m Y1gV83lYZ/qGzU4MtqXYDMI552djY30yibIREHVrTtX5fWsV1Dy8Fto=
    =yFtU
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)