linter failure

@mkoeppe Many thanks!

Documentation preview for this PR (built with commit 97eaac9) is ready! 🎉

I'll be honest, I only noticed this ticket because it is in Volker's merge queue. At first I thought it was a missed opportunity to drop some usage of stuff in sage.misc.package in doctest control and then to my horror, I noticed that it created new functionality in it and spread its tentacles in an area that was blissfully free of it before: "features". In fact, I took features as way to do things without sage.misc.packages. Well, no more!

sage.misc.packages is clearly an interface to consult the sage distribution packaging system. Its inclusion, use and any extensions goes against the effort of making sage more modular and pip installable as far as I am concerned. sage should be able to run independently of sage the distribution. That's the number one thing I would like to see split as a completely separate package and stopped being relied on for testing or anything else. This PR certainly hurt sage-on-distro as far as I am concerned.

I'll be honest, I only noticed this ticket because it is in Volker's merge queue. At first I thought it was a missed opportunity to drop some usage of stuff in sage.misc.package in doctest control and then to my horror, I noticed that it created new functionality in it and spread its tentacles in an area that was blissfully free of it before: "features". In fact, I took features as way to do things without sage.misc.packages. Well, no more!

sage.misc.packages is clearly an interface to consult the sage distribution packaging system. Its inclusion, use and any extensions goes against the effort of making sage more modular and pip installable as far as I am concerned. sage should be able to run independently of sage the distribution. That's the number one thing I would like to see split as a completely separate package and stopped being relied on for testing or anything else. This PR certainly hurt sage-on-distro as far as I am concerned.

I'm not sure I understand your point correctly. Is it about this from sage.misc.package import _spkg_type statement in src/sage/features/__init__.py? This is only used to classify the given feature in terms of the type of corresponding SPGK. If you know a way to achieve this without the import I'd appreciate your suggestion. Of course, one possibility would be code duplication. For this, however, AFAIK files under sage.env.SAGE_PKGS would also have to be read.

We could of course declare what features are standard/optional explicitly when we define a feature.
In downstream distribution packaging, build/pkgs is usually not available.

Of course, this is a minor point because referring to the features by group is only a convenience for developers.

In any case, this is something that we can address in a follow up related to #35790 and #35790

I am against adding any more functionality to sage.misc.package, I am against adding any more calls to it than there are now. What other python package queries a specific package manager to figure if something is here? Or a classification that is only available in one specific deployment case?

I'll posit that sage.misc.package should be refactored out of sage altogether and never be used to figure if something is installed by the official runtime. I'll have to rip all of this ticket out of sage-on-gentoo. My fault for not having ripped sage.misc.package out of the doctesting framework altogether a long time ago so people would not get any more ideas. And features was to be our way out of this mess and now it is polluted.

sage.misc.package should [...] never be used to figure if something is installed

This PR does not use sage.misc.package for that. It only uses it to query what packages are considered standard and which are considered optional.

But I'm working on a follow-up that you'll like.