On Wed, Apr 6, 2016 at 12:51 AM, Volker Braun <vbraun.n...@gmail.com> 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). 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. -- William (http://wstein.org) -- 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.
