On Wed, Oct 19, 2016 at 1:22 PM, Ximin Luo <infini...@debian.org> wrote: > Jeroen Demeyer: >> On 2016-10-18 17:52, Ximin Luo wrote: >>> (2) In the long run, one can think about splitting out sage.rings.integers >>> (and related things) into a small library "sage-types" or something like >>> that. Then sagelib and fpylll can depend on this, and there would be no >>> circular dependency, even when Debian or other distros try to build it. >> >> I do not understand how that would help you. I am proposing a solution >> >> (A) Split the Sage package in 2 packages (Sage-the-library + >> Sage-the-distribution) >> >> and you have various reasons why this doesn't work. Instead you propose >> >> (B) Split the Sage package in 2 packages (sage.rings.integers (and related >> things) + the rest) >> >> To me, (A) and (B) look very similar. Why would (B) work while (A) does not? >> In other words, why are the problems that you mention for (A) not applicable >> to (B)? >> > > It's a fair observation but there are important differences. > > In (A), the majority of the code exists in the dependency (sagelib). However > the tests for this huge body of code, exist in the dependant. This causes the > huge write-run-fix loop. And this is not really what a dependency system is > "supposed" to be used for, we don't have similar situations like this > anywhere else. > > In (B), the sage-types library is supposed to be a minimal library with a > stable API that doesn't change too often. The write-run-fix loop is greater, > but it doesn't get invoked nearly as often. This would automatically be true > just because the code base is smaller, but you could also put some extra > effort into making it very very stable. > > Furthermore, this pattern is very common. If we have a huge project and it > develops a utility that is useful to other smaller projects, it often gets > split out. For example we have the NSPR library from Mozilla which Firefox > depends on, GObject from GNOME, etc. > > Smaller projects that want to play with Sage integers, might not want to > depend on *all* of sagelib - it slows down testing. Possibly some of these > people would have sage installed already - but some of them might not want to > do this, or not want to install a whole development version of sage.
I agree--thank you for your insight on this. This has been discussed in various ways before. I know it was discussed before I ever came on to the project, but a recent(-ish) discussion was here: https://groups.google.com/d/msg/sage-devel/HAHulLZkKzw/Hc4aU_GDAgAJ The fact remains that there is a core sage library that implements all the essential types (i.e. sage.rings) and several other important core packages as well. The core package is still quite large on its own, but *can* be pared down quite a bit from the current "sage" package. There is rough, but very useful overview of the dependencies between sage's sub-packages here: https://groups.google.com/d/msg/sage-devel/29ndCD8z94k/pjFTq-XlAQAJ Almost all of these packages could be split off as separate, optional packages: * games * tensor * matroids * knots * interacts * crypto * logic * lfunctions * dynamics * sat * coding * game_theory * tests * sandpiles * media * manifolds I'm not saying they all necessarily *should* be split off into separate packages--there are good arguments for and against--but there's not much technical barrier to it, and it would make building, testing, and distributing the core of sage a bit easier (still not trivial, but easier). With more work on the "level 2" dependencies to untangle some of the circular dependencies, and to make more features optional (via runtime checks for dependencies of those features) we could make even more progress on modularization. There are good reasons Sage was developed in the monolithic way it was done in the first place. But I don't think those reasons hold up well as long-term solutions, and could be replaced with better, more careful engineering and development practices. Best, Erik -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
