On Thu, Mar 10, 2016 at 8:44 AM, Erik Bray <[email protected]> wrote: > On Thu, Mar 10, 2016 at 5:19 PM, Jeroen Demeyer <[email protected]> > wrote: >> On 2016-03-10 17:12, Erik Bray wrote: >>> >>> It might almost be worth rebuilding Sage's packaging on top of the >>> conda platform, so that we can eliminate a lot of the overhead of >>> developing a packaging system alongside sage. But the devil is of >>> course in the details, and I could also understand any wariness over >>> depending on a third-party system, over which we don't have full >>> control, for Sage-the-distribution's packaging. >> >> >> Never having used conda, some quick questions in case you know the answer: >> 1) Does conda support the same operating systems as Sage? > > No--this is one of the "details" that would count out sole reliance on > something like conda right now. Most significantly out of the Fully > Supported and Expected to Work columns in [1] being the Solaris > variants. A question I have is for how long does Sage intend to fully > support those platforms? There's nothing particular about conda that > would preclude supporting Solaris that I'm aware of (it doesn't rely > deeply on kernel-specific features or anything like that). Its lack > of support for Solaris is probably mostly due to lack of demand.
We supported Solaris because a customer specifically paid us to provide such support. Those days are long past. We could drop Solaris support and I think one person in the world (David Kirkby) would notice. > Anaconda (and subsequently conda) has been intended mostly for > individuals working on their personal / work computers, as installing > a full scientific Python stack was otherwise difficult for those > users. So it focused primarily on the OS's the majority of > researchers are using for their day-to-day work, less so on servers > managed by IT professionals. Yes, that's a difference with Sage -- the Solaris support did come from requirements of IT professionals... > >> 2) Does conda deal with non-Python packages too? > > Yes, that was one of the primary motivations behind developing their > own packaging system, rather than just relying on pip-installing into > virtualenvs. It also predated the standardization of the "wheel" > format, just barely. But it's well known that the wheel format is > still insufficient for certain types of binary dependencies. Their motivation (for conda) was pretty similar to my motivation for Sage's packaging system. > >> 3) Does conda support building packages in parallel? > > That I don't know. The main challenge to building packages in > parallel is just ensuring that all of a package's dependencies are > built first, right? I honestly don't know how Continuum builds their > full stack. Worth asking though. (I can't imagine that they would be against adding such functionality if it isn't there.) >> Do you consider conda superior than the Sage package system? Do you know of >> problems that conda has but Sage doesn't? > > I don't have deep enough experience with either to have a strong > opinion on the first question. I'll suggest a few points though: > Perhaps the single greatest advantage I can think of is the support > for multiple, simultaneous installation environments a la virtualenv. > If I had to guess this should be possible with Sage too by changing > around $SAGE_LOCAL and rebuilding, but I haven't tried that. You can > probably answer for me how simple that is. The advantage to conda > environments though is nothing needs to be rebuilt to be installed in > multiple environments--the existing binary packages can just be > unpacked to different locations, and there are explicit command-line > programs for managing environments. Another relevant thing: It is supported by a company that got over $20m in funding just in the last year (https://mattermark.com/companies/continuum.io). > > You can see more about the package format itself here: > http://conda.pydata.org/docs/build_tutorials/pkgs2.html#about-conda-build-recipe > As one would expect, it's not terribly different from what goes into > an spkg (there are only so many obvious ways to do this). I suppose > one advantage it does have (which you've seen me agitate for) is > slightly more structured metadata (it uses yaml, which means a yaml > parser needs to be bootstrapped before any other package can be > built). But this is a mostly superficial point, I think. > > I don't know what specific problems conda has, much less that sage > doesn't. I haven't built any large collections of packages for conda > so I haven't personally tested its limits. I know other people who > are happy with it though. > > To me the biggest reason for bringing up the idea of using it is less > whether one is better than the other, and more how much we can save > time and effort by leveraging an existing project. +1 > To be clear, I'm > not saying the existing effort has been misspent by any means. conda > didn't even exist until a couple years ago. It also doesn't have as > wide platform support. > > Best, > Erik > > [1] https://wiki.sagemath.org/SupportedPlatforms > > -- > 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. -- 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 [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.
