Hi all, So today I will be talking about subject that I in sage-on-gentoo have brushed under the carpet for years focusing on helping to be able to use more and more components of the system and ultimately get “sagelib” to be one such component.
Sagemath as a meta distribution of stuff has bad habits in regards to treating “sagelib” as a regular package. In short it doesn’t. A normal software package usually should only contains it own sources, vendoring as it is called should be kept at a minimum and some other best practise are that * the package can be tested after being built and before being installed * the package documentation be built usually after the package itself, but before it is installed and the documentation should be installed at the same time as the rest of the package. Some project offer pre-build documentation, as part of the package if it is small, or downloadable tarballs if it is large. It is also the way to go for particularly difficult to build documentation. I’d say Sagemath will eventually go that way. So, we have made progress on vendoring, sage-on-gentoo has been building Sagelib and the documentation as a regular well behaved package for years and I have only pestered about the testing. Modularisation may force some things about the testing and offer solutions to an unmentioned problem so far, optional dependencies. But my situation about being able to build the documentation is under threat and is hack-ish in any case. So how are we building, installing and testing the elements of “vanilla" sage at the moment: * sagelib is built and installed * using the sagelib install the documentation is built. It is not supposed to be possible to build the doc without installing sage first, which is why sage-on-gentoo’s ability is really a hack * testing is done on the installed elements, that includes running tests inside the documentation Instead of trying to fix the problem that you should be building the documentation before installing, the push to modularisation is currently used to enshrine the current situation. #30010 actually separate the bits needed to build the sage documentation in a completely separate package. So the situation is now: * install package A * install package B * make a package C that takes B and applies it to the install of A and install the documentation of A (not C). Can anyone point me to some other system that do that? Does anyone else thinks that’s a bit insane? #30010 is not all bad. Doc building elements have been buried inside sage_setup for a while and that wasn’t a good thing. sage_setup is mostly useless at runtime and shouldn’t really be installed unless some downstream packages can make use of it. But the doc building elements are already used by downstream packages (p_cohomology_group does), so installing them has some value. My own idea of modularisation would be that each package should be able to build its own documentation and be testable on its own, before install. Not to split the whole documentation as a separate package. I want to repeat #30010 is not without value. Having a helper package to build the documentation is not a bad idea in itself so long as it applies in the following order: * install B (the doc building helper) * build A, build A’s documentation using B * install A and its documentation No C please. If you read this far, thank you. That’s long enough for such a rant. François -- 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/BE94013F-0363-4E78-94AD-93390E8669EA%40gmail.com.
