On Thursday, June 15, 2023 at 6:38:39 PM UTC-7 William Stein wrote:
Have you worried at all about doctests/examples and the sage
preparser/global environment that is assumed in all the doctests?
I don't have plans to make any changes to this. The doctests do assume that
the global environment
On Thursday, June 15, 2023 at 7:18:25 PM UTC-7 Travis Scrimshaw wrote:
then we should make sure the doc is very clean.
Then I think you'll be happy when you notice that while going through these
doctests in detail to add # optional, I have been making massive cleanups
of docstrings.
--
Y
On Friday, June 16, 2023 at 10:18:57 AM UTC+9 Matthias Koeppe wrote:
On Thursday, June 15, 2023 at 6:03:41 PM UTC-7 Travis Scrimshaw wrote:
Perhaps this is the core question (for me): What do you expect most/casual
users to download and install?
It may be the wrong question because it seems
On Thu, Jun 15, 2023 at 6:19 PM Matthias Koeppe
wrote:
> On Thursday, June 15, 2023 at 6:03:41 PM UTC-7 Travis Scrimshaw wrote:
>
> [...] Some of it can be fixed by changing the nomenclature "optional" to
> something else as that suggests something a user should *add* to the
> installation.
>
>
>
On Thursday, June 15, 2023 at 6:03:41 PM UTC-7 Travis Scrimshaw wrote:
[...] Some of it can be fixed by changing the nomenclature "optional" to
something else as that suggests something a user should *add* to the
installation.
Fine with me to introduce something like "# module - sage.groups" w
On Thursday, June 15, 2023 at 12:23:55 AM UTC+9 Matthias Koeppe wrote:
On Wednesday, June 14, 2023 at 8:01:29 AM UTC-7 Tobias Diez wrote:
On Wednesday, 14 June 2023 at 05:37:15 UTC+8 Matthias Koeppe wrote:
- Some # optional annotations reduce the barrier for contributors, by
clearly signaling
On Wednesday, June 14, 2023 at 8:01:29 AM UTC-7 Tobias Diez wrote:
On Wednesday, 14 June 2023 at 05:37:15 UTC+8 Matthias Koeppe wrote:
- Some # optional annotations reduce the barrier for contributors, by
clearly signaling to developers "it's OK and definitely not your fault if
you don't unders
On Wednesday, June 14, 2023 at 7:53:25 AM UTC-7 Tobias Diez wrote:
On Wednesday, 14 June 2023 at 05:03:21 UTC+8 Matthias Koeppe wrote:
More specifically, when users of a modularized distribution make their
first steps to contributing to it, that's already difficult; and we do not
want to have t
On Wednesday, 14 June 2023 at 05:37:15 UTC+8 Matthias Koeppe wrote:
- Some # optional annotations reduce the barrier for contributors, by
clearly signaling to developers "it's OK and definitely not your fault if
you don't understand this doctest".
To be honest, this sounds like wishful thinki
On Wednesday, 14 June 2023 at 05:03:21 UTC+8 Matthias Koeppe wrote:
More specifically, when users of a modularized distribution make their
first steps to contributing to it, that's already difficult; and we do not
want to have to tell them "if you want to make this contribution, you first
have
And as I explained elsewhere, the # optional annotations also improve the
documentation for the benefit of the project.
The persistent optional tag that I suggested in
https://github.com/sagemath/sage/issues/35750#issuecomment-1590606293
would be explicit, visible in documentation, and at
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
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
On Mon, Jun 12, 2023 at 1:35 AM 'Travis Scrimshaw' via sage-devel
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 ma
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.
Y
On Thursday, June 8, 2023 at 5:11:28 AM UTC-7 kcrisman wrote:
how do you know which modules some random doctest you want to include
depends on?
By testing the modularized distributions and looking at the errors and
backtraces. (I'll expand on this in a separate post.)
This is done in #35095,
I've opened https://github.com/sagemath/sage/issues/35750 to keep track of
the idea of block tags. I have marked it as a wishlist item.
On Thursday, June 8, 2023 at 9:50:49 AM UTC-7 Matthias Koeppe wrote:
> On Wednesday, June 7, 2023 at 9:59:28 PM UTC-7 Kwankyu Lee wrote:
>
> We may also introdu
On Wednesday, June 7, 2023 at 9:59:28 PM UTC-7 Kwankyu Lee wrote:
We may also introduce a block tag like ":: optional - sage.modules
sage.rings.finite_rings" that applies to a block of lines.
Quick note that I'm all in favor of introducing a mechanism for such block
tags; it's of course a clea
Hi Travis,
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.
I'd s
Just ... wow. I know I don't get much of a say given my lack of recent
development activity, but this level of granularity does seem absurd. It
would certainly be a (psychological) barrier to development - how do you
know which modules some random doctest you want to include depends on? - as
Thanks for opening a discussion on this timely topic.
I think that Matthias is well aware of the benefits of the top-of-the-file
tags over the doctest tags, and is adding doctest tags only when they are
necessary (this is a lot of work for him). However, I do think that your
points
(1) hide un
28 matches
Mail list logo
