Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hide features (PR to migrated Trac ticket #34185) #35668

Merged
merged 25 commits into from
Jul 1, 2023

Conversation

soehms
Copy link
Member

@soehms soehms commented May 22, 2023

📚 Description

See the description of the underlying migrated Trac ticket. This fixes #34185.

📝 Checklist

  • The title is concise, informative, and self-explanatory.
  • The description explains in detail what this PR is about.
  • I have linked a relevant issue or discussion.
  • I have created tests covering the changes.
  • I have updated the documentation accordingly.

⌛ Dependencies

soehms added 18 commits July 15, 2022 09:03
…rac.sagemath.org:sage into hide_features_34185
@soehms soehms marked this pull request as ready for review May 23, 2023 05:28
@soehms soehms added this to the sage-10.1 milestone May 23, 2023
@@ -52,6 +52,10 @@ if __name__ == "__main__":
'if set to "all", then all tests will be run; '
'use "!FEATURE" to disable tests marked "# optional - FEATURE". '
'Note that "!" needs to be quoted or escaped in the shell.')
parser.add_argument("--hide", metavar="FEATURES", default="",
help='run tests pretending that the software listed in FEATURES (separated by commas) is not installed; '
'if "all" is listed, will also hide features corresponding to all non standard packages; '
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know what "non standard" means here; do you mean "optional or experimental"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you mean "optional or experimental"?

Yes! I changed this, to have it more clear!

@mkoeppe
Copy link
Contributor

mkoeppe commented Jun 17, 2023

linter failure

@soehms
Copy link
Member Author

soehms commented Jun 19, 2023

@mkoeppe Many thanks!

@github-actions
Copy link

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

@kiwifb
Copy link
Member

kiwifb commented Jun 23, 2023

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.

@soehms
Copy link
Member Author

soehms commented Jun 23, 2023

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.

@mkoeppe
Copy link
Contributor

mkoeppe commented Jun 23, 2023

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.

@mkoeppe
Copy link
Contributor

mkoeppe commented Jun 23, 2023

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

@kiwifb
Copy link
Member

kiwifb commented Jun 23, 2023

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.

@mkoeppe
Copy link
Contributor

mkoeppe commented Jun 23, 2023

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.

@mkoeppe
Copy link
Contributor

mkoeppe commented Jun 23, 2023

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

@vbraun vbraun merged commit a6ab2f6 into sagemath:develop Jul 1, 2023
@soehms soehms deleted the hide_features_34185 branch July 3, 2023 05:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

New doctest option to hide features
4 participants