On Tuesday, June 13, 2023 at 1:40:42 PM UTC-7 Tobias Diez wrote:
But I think it would be better to reuse tools (or at least their ideas)
that were developed exactly to manage and restrict dependencies between
different layers/modules of an application, such as
https://github.com/zyskarch/pytest
On Tuesday, June 13, 2023 at 1:40:42 PM UTC-7 Tobias Diez wrote:
On Wednesday, 14 June 2023 at 02:36:16 UTC+8 Matthias Koeppe wrote:
- Modularized distributions must be testable separately!
And why is this a desirable goal?
So that developers of modularized distributions can develop and test
On Wednesday, 14 June 2023 at 02:36:16 UTC+8 Matthias Koeppe wrote:
- Modularized distributions must be testable separately!
And why is this a desirable goal?
Integration tests almost by definition are testing multiple modules/units
and thus don't fit into this scheme.
Admittedly, the only
I eventually checked. You are requesting a lexicographic Groebner basis,
but since it's much slower than reverse lex. ordering, Giac tries first
revlex ordering, because if the ideal is 0 dimensional it would call FGLM.
The revlex basis computation is fast (about 2 seconds on my PC) but the
ide
On Tuesday, June 13, 2023 at 11:12:21 AM UTC-7 Tobias Diez wrote:
Maybe I'm misunderstanding the purpose of the modularized doctests. Can
someone explain me what they should test and what not?
As it says in
https://sagemath-tobias.netlify.app/developer/packaging_sage_library.html#testing-distr
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
On Tuesday, June 13, 2023 at 8:14:54 AM UTC-7 Tobias Diez wrote:
At the very least, I would propose to hide these optional tags from the
generated docs.
You *did* already propose to hide them,
in https://github.com/sagemath/sage/pull/35719#issuecomment-1575680194, in
response to which I expla
On Tue, Jun 13, 2023 at 4:14 PM Tobias Diez 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 env
On Tuesday, June 13, 2023 at 8:14:54 AM UTC-7 Tobias Diez 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
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
10 matches
Mail list logo
