-
-
Notifications
You must be signed in to change notification settings - Fork 523
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
Introduce os-dependent doctest tags # known bug: macos
, # known bug: linux
#36960
Conversation
Please adjust the scope of this PR. There is no need to back out |
src/sage/calculus/transforms/dft.py
Outdated
@@ -798,10 +798,10 @@ def idwt(self, other="haar", wavelet_k=2): | |||
sage: A = [RR(1) for i in J] | |||
sage: s = IndexedSequence(A,J) | |||
sage: t = s.dwt() | |||
sage: t # random arch dependent output | |||
sage: t # known bug, arch dependent output |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is a "bug"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See PR description.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is not a case that the PR description covers.
# known bug: macos
, # known bug: linux
I have edited the title and PR description to use the terminology that we use in the doctest framework. |
I would suggest to simplify and generalize the code as follows:
|
src/sage/doctest/parsing.py
Outdated
and tag not in available_software)} | ||
if extra: | ||
extra = { | ||
tag |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this reformatting seems excessive
Overall I'm still skeptical that introducing platform-specific "known bug" semantics is a good idea, but I don't object to creating this mechanism. As I wrote in #36372 (comment): "Introducing platform-specific skip flags in the source code is a departure from our long-standing practice. Our doctests are enabled by the presence of features, not disabled by an excuse. Where necessary, our downstream distribution developers have been externally maintaining their patches for tests that cannot pass on their platforms; and have been helping rewrite doctests so that they are suitable both within the Sage distribution and in downstream deployments." |
Hopefully this PR should produce something that makes everyone happy. One principle for this is to build based on what is already in sage and change things little by little as everyone agrees. Though this is a PR, we may start with discussing things from ground up. We want to renew existing tag Currently a doctest annotated with We want the tag What should happen if a doctest is annotated with For a doctest with The renewed |
Note that The explanations in parentheses should never be parsed - they are for humans to read. |
That is okay with me too. |
What does a patch do with the tests? Does it remove them? |
Maybe @kiwifb can comment |
As you know, we rather intend to run (previously skipped) doctests with "# known bug" empowered with platform check. Adding platform check means that we understand the nature of the bug more. So it is not so bad as "platform-specific tag that skips tests". |
I have had a policy of mostly try to deal with broken doctest through issue ticket or enforcement of dependencies when appropriate. I sometimes adopt patches for a dependency update early on but they rarely last more than one release these days. But really I only patch or remove stuff if I think it is completely broken otherwise. I do remove some doctest for stuff that I removed from sage. Stuff related to package management. Recently there has been some instance where I would have liked a tag to cover for stuff that is not always shipped when you use properly split sage. The tags we have may be sufficient provided we use them properly. I am thinking about test about |
This Issue has links to other downstream packaging: |
In this PR, we may focus on implementing the "# known bug" mechanism. Adding it to doctests may be done elsewhere with the "backing out" if necessary. |
In this PR, I didn't change the semantics of "known bug". I also don't see any real advantage of running the tests and then just hiding its output (people are even ignoring red ci checks, I doubt they will study the log for 'known bug' annotations). But changing the semantics would be fine with me. That can be done in a follow-up PR. |
Note that there is only one bug left that apparently is specific to conda. Hence, I didn't included any conda-specific exclusion mechanism here. |
About syntax, as Matthias said, better to use hyphen |
OK. Good to hear that. |
By the way, does colon |
Just deleting The proper way is to prepare a PR just for that as a sequel to this PR. Please don't rush. |
Yes, colon is also supported - it is actually the first example: sage/src/sage/doctest/parsing.py Lines 137 to 139 in e249bef
I think its better to be consistent with other standard tools than with sage's own custom conventions. Also |
c42b124
to
81b439f
Compare
Actually I don't care too much about this. Note that we have standardized on Also we need to make sure that |
I went through the conda logs of the past month with the following result:
Based on this analysis, I've now opened a couple of issues that track the new failures I've observed (if there were at least two instances of that failure on two different PRs), and added these via Since this PR now includes quite a few annotations of known bugs that are not conda specific and are also not in |
@tobiasdiez Thanks for looking through the logs, and I'm glad that this PR helped find a few bugs (perhaps it would be good to link to the issue numbers). But please don't unilaterally change tickets to blockers, especially if there is disagreement about the approach you've taken. Doing so further may lead to your removal from Triage again. |
In addition, you can't unilaterally decide that a ticket is no longer disputed. Removing that tag is not appropriate. |
I "discovered" these issues by going through the logs and not via this PR (see the last 10 or 15 of https://github.com/sagemath/sage/issues/created_by/tobiasdiez). The point of this PR, and why it should be a "blocker", is that these issues show up randomly as test failures for both the Build & Test and the conda workflow (as well as various portability runs) and thus impacting everyone. So far nobody mentioned any concrete negative consequences of this PR being a blocker (except of course of my rebase mistake) - on the other hand, there are clear benefits.
I've reacted to the reviewer's concerns, so there shouldn't be any disagreement anymore. |
Even if that's the case, it's better to give the reviewer a chance to weigh in themselves. |
Documentation preview for this PR (built with commit 518b577; changes) is ready! 🎉 |
The description of this PR seems to be outdated. At least I cannot find any functional change to how doctests are parsed in the changeset. Generally, the changes here look fine to me though. So, maybe you could clarify what this PR is supposed to do exactly and then I am happy to cast a vote here. Or maybe, this PR has diverged so much from the original plan that it's worth to create a new PR and close this one. |
@roed314 @saraedum @jhpalmieri I'm removing the "disputed" label, as the PR no longer sabotages the known-test-failures.json mechanism |
Setting to "needs work" -- indeed the ticket description is outdated, as the implementation of the platform-dependent doctest tag mechanism was split out from here and merged long ago. |
My general concern, as discussed previously in #36372, is that marking doctests |
So before deploying more |
<!-- ^^^^^ Please provide a concise, informative and self-explanatory title. Don't put issue numbers in there, do this in the PR body below. For example, instead of "Fixes sagemath#1234" use "Introduce new method to calculate 1+1" --> <!-- Describe your changes here in detail --> Author: @mkoeppe, based on @tobiasdiez's config in sagemath#36503. Adding a configuration for the ruff linter as proposed in sagemath#36503 is timely and uncontroversial. However, sagemath#36503 bundled this gratuitously with the controversial design of creating a `pyproject.toml` file in SAGE_ROOT. `pyproject.toml` -- by definition in PEP 518, PEP 621 -- marks a directory as a Python project, i.e., the source directory of a Python distribution package (sagemath#36503 (comment)). Generalizing the use of `pyproject.toml` to "[non-package projects](https://peps.python.org/pep-0735/#motivation)" is still subject to discussion in the Python community in [PEP 735](https://peps.python.org/pep-0735/) (Nov 2023). **The scope of PRs should be chosen to minimize friction, not to maximize friction.** sagemath#36726 (comment) Here we remove the artificial friction from the gratuitous bundling, by configuring ruff in `ruff.toml` instead. Configuration in ruff.toml and pyproject.toml has equal validity / standing per [ruff documentation](https://docs.astral.sh/ruff/configuration/#config-file- discovery). And this is the location of most of our other linter configuration files. Reference on previous common denominator PRs: sagemath#36666 (comment), sagemath#36666 (comment), sagemath#36572 (comment), sagemath#36960 (comment), sagemath#36960 (comment), ... <!-- Why is this change required? What problem does it solve? --> <!-- If this PR resolves an open issue, please link to it here. For example "Fixes sagemath#12345". --> <!-- If your change requires a documentation PR, please link it appropriately. --> ### 📝 Checklist <!-- Put an `x` in all the boxes that apply. --> <!-- If your change requires a documentation PR, please link it appropriately --> <!-- If you're unsure about any of these, don't hesitate to ask. We're here to help! --> <!-- Feel free to remove irrelevant items. --> - [x] The title is concise, informative, and self-explanatory. - [x] The description explains in detail what this PR is about. - [x] I have linked a relevant issue or discussion. - [ ] I have created tests covering the changes. - [ ] I have updated the documentation accordingly. ### ⌛ Dependencies <!-- List all open PRs that this PR logically depends on - sagemath#12345: short description why this is a dependency - sagemath#34567: ... --> <!-- If you're unsure about any of these, don't hesitate to ask. We're here to help! --> URL: sagemath#37452 Reported by: Matthias Köppe Reviewer(s): Giacomo Pope, Matthias Köppe
If someone else gets annoyed by the randomly failing tests: please feel free to use this PR as a starting point. |
Extend the
known bug
doctest tag by the possibility to hide these doctest errors only a certain platform. Use this to hide a few known (mostly randomly occurring) bugs. Also convert a few 'random' tags to 'known bug' if random was used in the sense "on a certain architecture, or with a certain dependency, this fails"`.Considered alternatives:
skip
tag. In most cases, known bug is however better name since these failures point to actual bugs. But some output is merely architecture dependent and in this case a genericskip
tag would be better.CI
env variable, or by explicitly specifying a baseline as in CI conda: Ignore baseline test failures #36678). This has the disadvantage that these known bugs may randomly popup on developers machines without adding any value in this case.random failure
orknown failure
tag with essentially the same meaning asknown bug
but limiting it to random occurrence. This idea didn't got much support in Fix/ignore all remaining test failures when run under conda #36372, and the randomness can easily be specified by an additional comment.Setting to blocker to hide #35715 and #36992 which annoyed devs before #36769 (comment). Also hides another unreported test failure in
sage_setup/clean.py
.📝 Checklist
⌛ Dependencies