On Thursday, April 7, 2016, Volker Braun <vbraun.n...@gmail.com> wrote:
> On Friday, April 8, 2016 at 12:19:57 AM UTC+2, William wrote: >> >> > You mean like in the Linux kernel, which uses a single monolithic git >> > repository? >> I think you are being sarcastic. > > > I'm only partially kidding. Why is the kernel not a collection of > packages? Because nobody wants half a kernel, and because the kernel > developers don't want to make promises about internal APIs. Similarly, I > want a car but please leave out the engine and two of the four wheels said > nobody ever. > > >> There are very good reasons to supporting both modularization > > > And there are reasons against as well. Its a tool, and with every tool > there are pros and cons. The old adage about the right tool for the right > job still holds. > > The only thing that I'm convinced is that going around and claiming that > modularization is the solution of all our problems (without making a > concrete proposal about what and how) is not productive. I agree that our > current dependency installation system sucks (but are we even talking about > that or do you mean the Sage library). > > You seem to think that pypi/whl is a suitable venue for binary > distribution. As I mentioned before, the author of whl doesn't think so for > what would be our use case. Of course its trivial to publish a pure Python > package on pypi. So a sagemath pypi package that just assumes that you have > a dozen obscure math libraries (+headers) on you system to cythonize > against? Is that what this thread is even about? > This thread is first and foremost about reducing the friction involved in making code that depends on the Sage distribution available to the world. Based on feedback I get from users, this friction is a very, very significant problem to the growth of Sage. There are projects with healthy package ecosystems. Examples include: tex, R, and Python. Often people write code for sage that sits in some branch on trac used by almost nobody for years and years. Just touching or working on that code involves way too much friction. In many cases that code would be much better placed in its own separate Python library. When it is fully up to snuff, we could make that Python library a standard part of the sage distribution of we want. Regarding your car analogy, sometimes it is far better if we can factor of some pieces of sage as separate libraries that we use, but which are also used outside of sage. For example, cysignals (I think from Malb). The broader community benefits and we also benefit since more people care about the code and work on it. It's a win-win. Remember that Cython used to be part of Sage and be called SageX... Making it separate was good for everybody. - William > -- > 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 > <javascript:_e(%7B%7D,'cvml','sage-devel%2bunsubscr...@googlegroups.com');> > . > To post to this group, send email to sage-devel@googlegroups.com > <javascript:_e(%7B%7D,'cvml','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. > -- Sent from my massive iPhone 6 plus. -- 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.
