On May 27, 2017 11:13 AM, "Volker Braun" <vbraun.n...@gmail.com> wrote:
In fact, if we were to do some major changes to the build system we should consider building on top of conda. In particular, we shouldn't just crap arbitrary files into $SAGE_LOCAL during build, but turn each package into separate binary achive that then gets installed. Can I just rein things back in here for a sec? I shouldn't have posted this on Friday--I don't want to get into any detailed discussions until I'm back at work on Monday :) I just wanted to say, that the whole point of what I'm proposing is that it's *not* a major change. I agree in principle with everything you're saying and would be happy to talk about bigger changes in a separate context. All I'm proposing are some very *minor* changes that change little about how Sage is currently worked on, while still being a quality of life improvement, in a way. In other words, it's something I can do now with maybe a few days of work instead of a major overhaul of everything. So I'd rather this thread focus on the details of those minor changes than any big ideas that may or may not go anywhere. * Going back in the git history then involves no recompilation, only re-extracting the cached binaries. * You can decide on a per-package level if you want to (re-)compile it or use a binary package * The whole thing can just be published as a conda channel, just run "conda install --channel https://sagemath.org sage" * Incremental binary updates for free * We could build on conda (-forge) instead of maintaining our own patch, python, ... packages. * A conda build recipe is just a better version of how we currently define packages (spkg-install -> build.sh, metadata in meta.yaml instead of scattered into multiple files) On Friday, May 26, 2017 at 11:49:03 PM UTC+2, William wrote: > On Fri, May 26, 2017 at 6:01 AM, Erik Bray <erik....@gmail.com> wrote: > [...] > > The extent and scope to which Sage "vendors" its dependencies, in the > > form of what some call "sage-the-distribution", is *not* particularly > > normal in the open source world. Vendoring *some* dependencies is not > > unusual, but Sage does nearly all (even down the gcc, in certain > > cases). I've learned a lot of the history to this over the past year, > > and agree that most of the time this has been done with good reasons. > > > > For example, I can't think of any other software that forces me to > > build its own copy of ncurses just to build/install it. This was > > Maybe Anaconda? > > https://anaconda.org/anaconda/ncurses > > The approach in Sage is indeed very rare, but it's interesting that > another similar situation is with another big Python computing stack > (Anaconda), which was developed independently. In any case, it's > worth mentioning Anaconda in the proposal. > > -- William > -- You received this message because you are subscribed to the Google Groups "sage-packaging" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-packaging+unsubscr...@googlegroups.com. To post to this group, send email to sage-packag...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/ msgid/sage-packaging/a9a640d6-6fec-40b0-b8f2-249c3dae10db%40googlegroups.com <https://groups.google.com/d/msgid/sage-packaging/a9a640d6-6fec-40b0-b8f2-249c3dae10db%40googlegroups.com?utm_medium=email&utm_source=footer> . For more options, visit https://groups.google.com/d/optout. -- 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.
