We are observing disadvantage of a long thread.
It is also very useful to have it all in one thread though. 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. I completely agree with this point. On an individual developer level, it is less work if he can focus on "a smaller sage library" (sagemath-number-theory) This is directly contradicted by your previous point as the individual developer needs to understand and check (!!) how the changes affect all of the other components, and how different configurations of components can require additional code complications or adding "magic" things (e.g., "# needs XYZ"). In our current model, the developer still is just focused on the section of code they want to change. 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. As I mentioned above, this is a burden on *all* developers. There also becomes an additional barrier of core developers having to explain to new developers why they need to add stuff to get some complex test to pass. 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. We should be more judicious about cutting off pieces as dependencies that are useful to the broader community. I continue to remain highly skeptical that the proposed modularization will have a net positive impact on how Sage interacts with the Python ecosystem, such as increased developer contributions to Sage or use of the modular parts of Sage. 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, ... Cognitive stress has no relation to the size of a software package, but instead the complexity of its installation. Consequently, having more pieces means the user needs to make more decisions about what to install and increases the number of points of failure due to (often nontrivial and subtle) interactions. The user also doesn't care about testing. 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 sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/388935fb-f1e4-4f9f-9733-4bd0d8ea9a4fn%40googlegroups.com.
