On Thursday, April 7, 2016 at 11:19:57 PM UTC+1, William wrote: > > On Wed, Apr 6, 2016 at 12:51 AM, Volker Braun <vbrau...@gmail.com > <javascript:>> wrote: > > On Tuesday, April 5, 2016 at 8:44:45 PM UTC+2, William wrote: > >> > >> [...] toward standard open source practices. > > > > > > You mean like in the Linux kernel, which uses a single monolithic git > > repository? > > I think you are being sarcastic. It's hard to tell on the internet. > > > Really, modularization is not a useful goal in of itself. And it comes > with > > its own sets of issues, see the left-pad fiasco last week when the > nodejs > > clown boat caught fire. > > There are very good reasons to supporting both modularization and much > more standard approaches to packaging. It's unbelievable to me that > somebody as technically smart as you and knowledgeable about sage and > software doesn't see this as obvious. Since -- based on responses -- > almost nobody else in our community seems to get this either, I'll > just forge on and come up with the future approach to sage development > myself (even though I don't want to). >
while better packaging would be great, and ability not to install (or uninstall) parts that one never uses (e.g., as far as I am concerned, I don't need finances/, games/), I fear that "full modularisation" efforts in case of "core" Sage are akin to surgery attempts to separate siamese twins. I cannot imagine separating groups, NT, algebra, linear algebra, symbolics, calculus, combinatorics/graph theory; they are too much interdependent for this. IMHO things like improving the build system are more urgent (and improving the build system would lessen the feel that Sage is too big...) > William > > > > > You can do "import sage" right now, it works. The question is, what do > you > > expect it to do. The basic dichotomy is > > > > * either this imports something like the "undergrad curriculum", all > kinds > > of rings and groups and plotting and ... (we are basically here, and > this > > necessarily has a longish list of dependencies). > > > > * or this imports some piece of Sage (integers?) that is super-fast to > > compile. But you want elliptic curves? Never heard of that, maybe if you > > install the sage-elliptic-curves (or maybe the competing and > incompatible > > sage-riemann-surface). > > > > As long as the goal of "import sage" is to give you something like the > > feature set of Sage right now we don't benefit from modularization. That > is > > just a tautology, the goal is just not a modular one. We'd just shoot > > ourselves in the foot if we split things into multiple interdependent > > packages that then must be upgraded in lockstep. > > > > It would still be useful to straighten out the Sage startup circular > import > > game, have some core feature set (~= sage.rings) that must be importable > > (and usable) by itself. This could be shipped as a separate package even > if > > its not a separate repository. It just requires tooling to keep > dependencies > > straight. And as I mentioned before, Python3 has better namespace > package > > support... > -- 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.
