On Friday, March 11, 2016 at 11:03:13 AM UTC, Erik Bray wrote: > > On Thu, Mar 10, 2016 at 10:45 PM, Michael Orlitzky <[email protected] > <javascript:>> wrote: > > On 03/10/2016 03:23 PM, William Stein wrote: > >> > >> Could you say more? (I mean about what you might imagine Sage could > >> do to improve -- both incrementally or dramatically?) I'm sure > >> everybody really appreciates your experience, and speaking up about > >> this here. > >> > > After that work has been completed, the spkgs and sage-install could go. > > Updating a Sage depencency at that point will involve a one-line change > > to configure.ac, and maybe an update to a homebrew package (depending > on > > how much of that burden we take on). Windows users get a VM, same as > > always, unless someone knows how to package things for Cygwin. > > I don't think this was intentional, but the degree to which this > entire post ignores / dismisses Windows comes off as a bit flippant. > Maybe you didn't know this but I'm working on getting sage and its > dependencies working on Windows. The VM approach has never been a > real viable solution. >
how would you deal with GAP/libGAP? (in particular, given that there are basically two branches now, HPC-GAP and "classic" GAP)... > > Eventually, packaging for Cygwin is certainly possible. Cygwin packaging seems to be harder than for MSYS2 (for Cygwin installer is a pain in the neck, IMHO) > There's also > now Chocolatey which is sort of like a "homebrew for Windows". > Finally, and again, the advantage I see with conda is that it works on > all 3 OS's (that's nothing to do with the packages themselves > working--just the system). > > That said I agree with everything else you wrote, and the sort of work > that would make it possible to build and use conda packages for sage > is by and large the same work that would make any other packaging > system usable for sage and its dependencies--that is--the work of > decoupling the sage distribution from the packaging / build system it > uses. > > > We can still offer big binary packages -- that doesn't have to change -- > > but building from source should be as easy as building the Sage python > > library. You can get all of the dependencies installed easily by > > installing Sage with your package manager. If you want to modify one of > > Sage's dependencies, that should be possible -- just make your change in > > the upstream project and `make install` it to /usr/local which will then > > be picked up when you rebuild the Sage library. > > I agree. But if I understand correctly William's comment about > "change in focus" is that "build everything from source" is not an > ideal default for the vast majority of people, including developers. > > I am new to this project and spent a good amount of time last week > trying to better understand what exactly is happening when Sage is > sitting there taking hours to build on my laptop, and what exactly I'm > building. The example that struck me--that I keep coming back to--is > that everything kicked off by building GNU patch. And I kept thinking > to myself--why the heck are you building patch for me? I already have > a perfectly good patch program--the exact same version in fact. > Looking at the SPKG.txt I can understand why--patch isn't the same on > all systems. But really (especially these days) that should be a > minority case, and Sage should have just used the `patch` I have. > well, yes, there is one Sage package that is "dual" in the way you would like patch to be, it is gcc. So this is doable, just needs a fix... > > It's a minor example that only takes a tiny bit of time to compile, > but from there I came to understand the large number of other such > dependencies. > > *Even if* Sage absolutely required me to have a special version of > patch to build packages from source (and indeed, even assuming I want > to build from source at all), it would have been much quicker to > download, unpack, and install a binary package that has already been > built for me. Yes, for linear algebra libraries and like I may want > to recompile them and their dependencies for my platform. But that > doesn't mean I gain anything from building *everything* (or even most > things) from source. That's why I didn't use gentoo for very long > last time I tried it--I don't have time for that. Neither do most > users. > there is a special mechanics to avoid buildling Atlas when you build Sage, see the installation manual. Although I imagine it ought to be more the way gcc package is. > So anyways, I agree building from source is good to have. But it > doesn't need to be the default. > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
