What about a completely different approach: Instead of annotating the doctests, simply ignore test blocks that fail due to a thrown import error (or missing feature error) of a package that is not installed in the modularized test environment? That might hide some edge cases, but would in total be a less intrusive way to handle things.
At the very least, I would propose to hide these optional tags from the generated docs. On Monday, 12 June 2023 at 16:50:11 UTC+8 Dima Pasechnik wrote: > On Mon, Jun 12, 2023 at 1:35 AM 'Travis Scrimshaw' via sage-devel > <[email protected]> wrote: > > > > Hi Matthias, > > > > Happy to see that you are curious regarding the modularization project, > but I don't think it's a good approach to start this discussion with claims > that sound authoritative ("nobody will actually maintain", "does not > scale", "nearly all end users", etc.) and a policy proposal. > > > > > > Yes, you're right. I do not have any hard analytic data to support what > users want and are doing, and that observation is based solely on my years > of experience with working with Sage, going to and speaking at SageDays, > and convincing people to start using Sage. However, there is clear evidence > that the current approach is not scaling by the amount of work that is > going in and frequent updates/fixed that is needed to be done. Currently, > only you are the one doing this. > > What exactly is not scaling? "Vendor everything" approach abandoned ~9 > years ago obviously didn't scale. > I think we're not unvendoring things aggressively enough, and that's > what we quarrel with Matthias about. > > I'm about to start a round of discussions here to lead to a vote to > remove vendored gcc and gfortran. > We also should be getting rid of Sage-nonspecific things such as > vendored Python (with the needed dependencies such as openssl), > and vendored Jupyter and its huge slew of its dependencies (for the > latter Matthias is on board, I think). > > It's also not correct that modularisation is currently only done by > Matthias. E.g. most recently I worked on unvendoring of Maxima. > I worked on doing some abstract classes for parts of sage.coding, I > worked on spinning out prime counting stuff into a separate > pip-installable module (that was in 2021, though), etc. > > The interdependecies of parts of Sage library on each other are > decreasing, and this is certainly a big deal in terms of > updating/fixing > things. (Not importing from sage.all in the library is a big deal). > > Dima > > > Some of that is the lack of discussion (which I would like to have > seen given the large scale nature of this change, which is implicitly > setting policy by default). You can disagree with my conclusions and > proposal, but I want to actually talk about that rather than having > dismissive comments. Can you provide any specific counterpoints and > your expectations? What you posted on the other thread does not > address any of these. > > > > Best, > > Travis > > > > -- > > You received this message because you are subscribed to the Google > Groups "sage-devel" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/84fbc2ed-00c8-4ca6-8aa7-d4c74e8c2455n%40googlegroups.com > . > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/cc125172-2413-4416-b871-f4fdc606a4c7n%40googlegroups.com.
