public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Eli Schwartz <eschwartz93@gmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] RFC: Block ebuilds installing tests to ${D} by default
Date: Thu, 1 Feb 2024 16:38:10 -0500	[thread overview]
Message-ID: <70c91f58-bf2f-48e9-8fa5-e67056114231@gmail.com> (raw)
In-Reply-To: <9cd24274a8502f92e20fff640c19a63560bfdc4c.camel@gentoo.org>


[-- Attachment #1.1.1: Type: text/plain, Size: 3164 bytes --]

On 2/1/24 4:03 PM, Michał Górny wrote:
> I suppose you are referring to dev-lang/python here.  Unfortunately,
> removing tests from it is a non-trivial problem.  As I've mentioned to
> you before, there are packages that actually import modules form the
> test directory.
> 
> Remember that Gentoo has a policy of following upstream, and this policy
> is specifically targeted towards developers who expect Gentoo to
> be a good baseline environment for developing packages.  By explicitly
> diverging from upstream default install by default, we are effectively
> creating an incompatible Python environment and requiring users to go
> through extra steps to restore upstream compatibility.


The "following upstream" argument is extremely weak.

eschwartz ~/git/cpython $ ./configure --help| grep test
  --disable-test-modules  don't build nor install test modules


Clearly, upstream is giving you loud and clear permission to refrain
from installing this. They even have a split in their Makefile variables:
- LIBSUBDIRS: things that are always installed
- TESTSUBDIRS: test files that you can disable


> What's worse, Python development is often done via virtual environments.
> For regular Python packages, all kinds of Gentoo divergence can be
> easily "reverted" by installing the upstream packages inside the virtual
> environment.  However, this isn't the case for dev-lang/python itself --
> by stripping it down we're effectively creating virtual environments
> that are not fully functional and whose functionality cannot be restored
> without actually rebuilding dev-lang/python.


This... I sort of hear the argument, and at the same time I kind of do not.

https://docs.python.org/3/library/test.html


"""
Note

The test package is meant for internal use by Python only. It is
documented for the benefit of the core developers of Python. Any use of
this package outside of Python’s standard library is discouraged as code
mentioned here can change or be removed without notice between releases
of Python.
"""

Any users who are developing packages on Gentoo and finding that a
USE=pythontests choice is producing a "not fully functional" virtual
environment which requires rebuilding dev-lang/python to fix, would be
better served obeying the pleading and impassioned requests from
upstream CPython and NOT using the `test` module. Not even `test.support`.

However there are definitely packages in the wild that ignore this, and
require the "test" module.


> This is going to be a lot of effort, considering that
> effectively developers would have to run without test suites installed
> to detect missing dependencies, and then rebuild dev-lang/python every
> time they are about to run tests in a package that actually requires
> these files.


This I think is the biggest issue. It's a relatively simple problem to
solve for any distro that supports a single package recipe producing
multiple packages -- but portage does not (yet!) support one ebuild that
produces two gpkg.tar files, one per "component" of the full set of
installed files.


-- 
Eli Schwartz

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 18399 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2024-02-01 21:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-01  8:15 [gentoo-dev] RFC: Block ebuilds installing tests to ${D} by default Robin H. Johnson
2024-02-01 19:44 ` Mike Gilbert
2024-02-01 21:03 ` Michał Górny
2024-02-01 21:38   ` Eli Schwartz [this message]
2024-02-01 21:52     ` Mike Gilbert
2024-02-01 22:06       ` Eli Schwartz
2024-02-01 23:07 ` Andreas K. Huettel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=70c91f58-bf2f-48e9-8fa5-e67056114231@gmail.com \
    --to=eschwartz93@gmail.com \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox