We are observing disadvantage of a long thread. At some point, other participants forget the context in which a participant write a comment.
Dima and I were talking about a fictional sagemath-number-theory distribution package. I imagined a user/developer who installed sagemath-number-theory, and is developing some mathematical code. I claimed that running all doctests in sagemath-number-theory on his local platform would take less time than running all doctests in sagemath-standard. > On Thursday, October 3, 2024 at 1:18:44 PM UTC-7 Dima Pasechnik wrote: > > Why is it quicker than running ./sage -t src/sage/lfunctions src/sage/rings/ > (perhaps few other should be added) on a full sagelib install? I didn't claim that. On Thu, Oct 3, 2024 at 11:01 PM Matthias Koeppe > The main point of testing a modularized distribution is not speed but to protect against modularization regressions. > Testing the modularized distributions is not the same as passing a subset of files to the doctester. Matthias is talking about testing modularized distributions to check if they work together well. This will be done in github ci. We are taking about a particular example - of developing a piece of number-theoretic functionality, and how using only sagemath-number-theory distribution might benefit the developer. It was suggested that it might be quicker with sagemath-number-theory, as it would only test a part of the sagelib. I pointed out that an option to test a part is already here, for long time. And on the other hand, as at some point *one* would need to test the whole sagelib, Yes. The one is github ci. it's more work with the modularised system, not less On the project level, It takes more work to provide more products (distribution packages) to users. On an individual developer level, it is less work if he can focus on "a smaller sage library" (sagemath-number-theory) My point is that the benefits of modularisation are unclear, there are more tests to run, more complexity to understand, for seemingly no gain. Like our github ci, "more tests to run, more complexity to understand" is a burden upon the core developers maintaining the project. The motivation of the modularization project is to reduce the burden who only needs some portion of the sage library, and wants to use and develop the portion within the python ecosystem. An individual mathematician who only needs some portion of the sage library may install only his favorite distribution package. There are obvious benefits of using smaller software package: less time in installing and testing, less number of failure points in installing and testing, less cognitive stress, ... -- 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 sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/d5016525-10ce-4517-9b79-ae93d018308bn%40googlegroups.com.
