On Monday, April 22, 2024 at 2:22:36 AM UTC-7 Martin R wrote: I still don't see why you would name these distributions as you do, and why you collect them as you do.
Above I explained, "I introduce these packages to create *discoverability* for potential consumers of portions of the Sage library. (pip-installable packages are often named after the functionality that they provide.)" For example, as far as I know, symmetrica is currently essentially only used by symmetric functions, Schubert polynomials. So, if symmetrica is such a burden to install, why would you want to install it if you don't need them? *symmetrica*, as a single dependency on its own, is not "such a burden to install". Dependencies can become a burden simply if there are too many of them. I have defined the distributions with an eye on keeping the number of distributions and the complexity low. But there's no dogma. If the community finds it useful, then a distribution **sagemath-symmetrica* could later be split out from *sagemath-combinat* and can become either a required dependency or an optional dependency of *sagemath-combinat*. On the other hand, combinatorial species will, after this summer, heavily depend on gap. Does this mean that you would want to move this part into sage-groups? If it has a build-time dependency on sage.libs.gap, then it would likely be shipped by *sagemath-gap*. If it's merely a runtime dependency, it does not really matter from a technical point of view which distribution ships it. (Once more I refer to the chapter in the Developer Guide that explains the different types of dependencies, https://doc.sagemath.org/html/en/developer/packaging_sage_library.html#dependencies-and-distribution-packages) It could then be advertised, for example, as an "extra" of *sagemath-combinat* so that it can be installed as "pip install ' *sagemath-combinat*[species]'" or "pip install '*sagemath-combinat*[gap]'", like the existing definitions of extras that make it possible to do "pip install '*sagemath-combinat*[modules]'" for typical algebraic combinatorics features. https://github.com/mkoeppe/sage/blob/t/32432/modularization_of_sagelib__break_out_a_separate_package_sagemath_polyhedra/pkgs/sagemath-combinat/pyproject.toml.m4#L40 I gave more examples for the use of such extras in my 2023-06 sage-devel post "Modularization project: V. The blocs", https://groups.google.com/g/sage-devel/c/kiB32zP3xD4 Apart from the strange naming, I don't think that it will make anybody happy if dependencies change frequently. Hard to tell what exactly you find strange about the naming if you're not more specific. In https://github.com/sagemath/sage/pull/36964#discussion_r1564162445 and below, you already expressed surprise that trees and posets are in *sagemath-graphs* and that symmetric functions are in *sagemath-combinat*. I'll just say that the existing design is the result of years of work that has taken all of the following into account: - the technical constraints of Python packaging, - the actual dependencies of the Sage library, - discoverability by users, - attribution and visibility for upstream libraries/projects, - the overall complexity, - and the potential for connecting the new distributions to communities of users and developers. But as I said above, there's no dogma as to what exactly goes into what distribution, and the Sage developer community will be able to change it over time, like everything in Sage. -- 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/46b37837-f0ea-4e65-aee1-9864007ea164n%40googlegroups.com.
