Maybe I'm misunderstanding the purpose of the modularized doctests. Can
someone explain me what they should test and what not?
My thought was that when you declare a new module, you run the doctests of
that module. They usually break for two reasons:
a) some real dependency was not declared for that module - in this case,
add the dependency and run the tests again.
b) some doctests require a library that is not a dependency of the original
module - in this case, add an optional tag to the failing doctest (current
solution)
My proposal would be in b) to add it the offending import to a whitelist
("test dependency of module xyz") and then all doctests for module xyz are
ignoring import errors for these whitelisted dependencies. So in short,
instead of annotating each doctest you annotate the module.
On Tuesday, 13 June 2023 at 23:46:26 UTC+8 Dima Pasechnik wrote:
> On Tue, Jun 13, 2023 at 4:14 PM Tobias Diez <[email protected]> wrote:
> >
> > 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?
>
> How do you see the doctest framework distinguishing "real" import
> errors from the ones caused by modularisation?
>
>
>
> > 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
> .
>
--
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/f5d07321-1e94-45f3-8a15-974a6cdca0b1n%40googlegroups.com.
