On Sat, May 27, 2017 at 1:51 PM, Isuru Fernando <isu...@gmail.com> wrote: > On Sat, May 27, 2017 at 4:46 PM, Erik Bray <erik.m.b...@gmail.com> wrote: >> >> 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. > > > If you can do this, then it'll be simple to use conda. All the dependencies > are in `conda-forge` for linux (osx needs only a cython upgrade), so it's a > matter of telling the build system to use the conda packages as system ones.
Hi Isuru, Exactly! With these changes, building Sage in any environment is the same as before. But if building in a conda environment (just as an example) this is a way to get it to use the conda packages--selectively if needed. It can also be useful for finding out what packages are missing, or don't quite meet Sage's needs. If we wanted to go further one day and replace Sage's old build system entirely with something based on Conda that's a good thing to talk about (as we already have before), but this is a small stepping stone to that. Erik >> 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. >> >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> 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/CAOTD34aUu25iha%3DnQStKWZWLrHgT_TU3KpNiyqZEk1H9yN-fNA%40mail.gmail.com. >> >> For more options, visit https://groups.google.com/d/optout. > > > -- > 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/CA%2B01voPzQvGzEsVvD5o%2BJAgfRiYyQnGiWZHSwKQD5ZzAXUOyMw%40mail.gmail.com. > > 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.
