On Wed, Aug 24, 2016 at 6:58 PM, kcrisman <kcris...@gmail.com> wrote: > > > On Tuesday, August 23, 2016 at 4:54:45 PM UTC-4, leif wrote: >> >> kcrisman wrote: >> > >> > Make R optional? (Nothing in Sage depends on it, except for the >> > interface to it, including Rpy2.) >> > >> > Gosh, R has been standard for*ever*, practically, >> >> Hört sich nach Schwäbischem Dreiklang an. >> > > Not being from southern Germany, I have no idea what you're talking about > ... > >> >> >> > and is often heavily >> > advertised as a good reason to use Sage. There are certainly many who >> > have been using them together (as mentioned, obviously nowhere near the >> > number of "pure" R users, but still we definitely get queries about this >> > regularly) >> >> Well, I guess the ratio of R-thru-Sage users to Sage users is as >> "negligible" as that to pure R users. ;-) >> > > Just today: > http://ask.sagemath.org/question/34571/linear-regression-with-r-in-sagemath/ > > I'm not saying it's a huge user group, but if Sage is actually mathematics > software and not "people in number theory" software, it would be nice to > have good stats and the tons of optional R packages just waiting. It has > definitely been a selling point in many discussions I've had, and I and > others have used it ourselves. Note that even for "brial"/polybori which > presumably is not a huge user base either we made things work out. > > How this relates to "Sage-the-package" versus "Sage-The-distro" I don't care > as long as it's still in "sage-the-distro".
Absolutely it should be--by default in fact, since it already has been. It would be a major regression to remove it. I think maybe even a better distinction than "sage-the-distro" is to call it "SageMath, the Application". As far as users of the application are concerned I agree the it should have the goal of being a general purpose stack of mathematics software. For short I'll call the application/distribution SageMath in (camel-case) and the Python package "sage" since that's what the actual package is called. But treating that larger software stack, and the `sage` Python package as one in the same makes development on the latter more difficult, and probably ultimately the former as well. For example--continuing with R as the test particle--say I'm a SageMath user who makes heavy use of R for my statistics, and like being able to use R with sage. What happens when a critical bug is fixed in R, and a new patch release comes out (something Sage, by the way, doesn't even have but should). How do I get that patch release? Well I have to wait for a new version of sage (the package, and everything else that comes with it). That might include a bunch of other new dependencies that I didn't really think I needed. Possibly even API breakage elsewhere (though fortunately sage itself is normally pretty good about that). Better would be to have a stable version of SageMath the application stack, with a stable version of sage at its core, to which one can receive small patch upgrades both to sage, as well as to the other software in the stack, and only make "big" upgrades if I need to, or want to be on the bleeding edge (it's also perfectly possible and reasonable to have several at once--a stable version used for work, and a development or experimental version in a different install path). Another option of course is to provide one's own R installation and have sage use that instead of the R installed in the SageMath stack. This should definitely be doable for most of sage's dependencies, especially the optional, non-core ones (and there has been some progress on that front). In sage there should be at most a way to get the path to the R to use, and a minimal (best guess at least) version check for whether it's supported by the interface. Jeroen and others have pointed out examples where it isn't always so nice--for example getting important bug fixes bundled up with major API change bombs in ways that are difficult to extricate. This is sort of thing is certainly a pain to deal with--sometimes it can force an otherwise unwanted upgrade. But a model that separates SageMath from sage doesn't preclude that either. It just means that the stable release of the former may not get all fixes all the time. In practice this is rare. Many packages are well-behaved in terms of their versions, and maintaining stable release lines for a decent amount of time. For those that don't, most of the time at worst it is the job of a downstream integrator (like us) to manually cherry-pick a sensible patch set. Most bug fixes are not hard to backport if they're relevant to older releases. On Wed, Aug 24, 2016 at 6:57 PM, leif <not.rea...@online.de> wrote: > A matter of introducing more package "types" (such as "mandatory", > "shipped by default", "installed by default" etc.), and changing mainly > some (build, release and dist) scripts accordingly. (In addition, > portions of the Sage library would of course have to get adapted as > well, but that's more or less copy-pasting from what we already have, > although we might improve the existing code -- including doctests -- to > become more generic.) Yep. It also helps to better make a distinction between (required/optional) build dependencies, and (required/optional) runtime dependencies. And on top of that it would really help to have a more complete list of which dependencies are (required/optional) for sage itself, as opposed to being secondary or tertiary dependencies. > Erik, have you opened some ticket (or thread, wiki page) regarding that? > (Sage "repackagers" will certainly be interested in such as well.) I tried to start a discussion about this a long time ago on this mailing list, but I dropped the ball on it. Got spread too thin on other issues and this was maybe a bit "big" to tackle at the time. Having a ticket in Trac would be a nice way to prevent the issue from being lost though. Of course, what we're talking about here is really several issues--the biggest of all being the proposal to better separate SageMath and sage. But a metaticket could get the ball rolling and spawn child tickets. > P.S.: Alternatively using system-provided packages for optional or > mandatory components (and improving the build system w.r.t. version > requirements) is related, but can IMHO be addressed independently. Ah, right! I meant to bring that up above. I have now edited my message to do so. I agree it should be possible, but is also slightly tangential from separating SageMath and sage. > './configure ... && make download && make' should just work as one would > perhaps expect, namely making sure all prerequisites (depending on the > configuration) are present (modulo things like e.g. Xcode of course, but > in some cases we could create 'sudo apt-get install ...' scripts for > example). Yep. Best Erik -- 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.
