>From Drew: "+1. At the LMFDB workshop in Bristol last week we ended up giving a lot of people accounts on the main LMFDB machine in Warwick simply so they wouldn't have to go through the time-consuming (and somewhat error prone) process of building Sage 7.1 on their laptops and installing the additional packages that LMFDB requires, even though in some cases this meant teaching people how to use vi so they could edit files remotely when they needed to (!).
BTW, there will be a new release of smalljac in the not-too-distant future that fully supports genus 3 curves (and does not require you to hardwire the genus at compile time -- BTW, contrary to what it says on trac server, the current version of smalljac (and this has been true for at least 5 years) handles genus 1 and 2 simultaneously out of the box, there is no need to recompile. Drew" On Tue, Apr 5, 2016 at 11:44 AM, William Stein <wst...@gmail.com> wrote: > Hi, > > This was a comment I just put on trac #965: "I would make a completely > separate python package, maybe called pysmalljac, which builds > smalljac and makes it usable from Python. It would be on github and > pypi. That's how most Sage development should be done. What a > monster I've created by following the Magma way of doing things > instead of the standard open source best practices..." > > I am recommending to absolutely everybody I talk with about Sage > development that we switch from our current massive monolithic > centralized approach toward standard open source practices. Namely, > lots of smaller libraries, standard open source practices, etc. It > would be really valuable to have a thread on sage-devel about how to > more systematically support this. > > Some thoughts: > > - For now, work can be done that is valuable but doesn't have to > impact the current sage/trac workflow. For example, somebody might > create an awesome Python package that does BLAH and depends on the > core Sage library (what you get via "import sage" now). > > - There are 77989 examples of Python packages at > https://pypi.python.org/pypi > > - This is pretty useful to read: > https://python-packaging.readthedocs.org/en/latest/ > > - In the beginning I put everything into one library, since it was > small. Then it started getting bigger and in 2006, 2007, etc. we > talked a lot about splitting up Sage, having smaller packages, etc. > There was a lot of momentum and it was pretty clear to all the CS-type > people involved in Sage (who knew about programming from more than > just Sage) that this is what we needed to do. People like Martin > Albrecht and David Harvey. Then those people all got jobs and > couldn't work on infrastructure aspects of Sage... and nothing > happened in this direction. > > - PSage was an attempt at something like this where I could work > out how to build Cython code in parallel, etc., etc. using more modern > packaging. That was in about 2011, and then I stopped to work on SMC > fulltime for several years, hence work on psage stopped, since I can > only do one thing at a time. > > -- William > > -- > William (http://wstein.org) -- 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.
