On Mon, May 9, 2011 at 4:01 PM, Robert Bradshaw <rober...@math.washington.edu> wrote: > On Mon, May 9, 2011 at 2:57 PM, Ondrej Certik <ond...@certik.cz> wrote: [...] >> I was thinking about this a lot yesterday, and there are a lot more >> issues to resolve, than it seems at first sight. In particular, some >> packages like Python is doing some recompiling of modules (I think, >> but maybe I am wrong) and some other stuff to the place where it is >> installed. Some other packages (setuptools?) are modifying some stuff >> as well (at least I read it somewhere). >> >> Pretty much, as long as the "installation" is just copying of files, >> then it should work. But if you also need to modify some stuff after >> installing it (post install script in Debian/Ubuntu), then things >> become more complex. >> >> With our current approach, one is free to do any kind of necessary >> tweaks in $SPKG_LOCAL (=SAGE_LOCAL) to make things work. Usually by >> the build system of the package itself. > > True, but I can't think of anything in Sage where one needs to modify > the environment any more than put a file somewhere that it's > accessible (though such a thing could be possible). > > I agree a general solution is much more subtle.
One would have to try and see. Nice thing about the current SPKG format is that it is extremely simple, and although it doesn't allow uninstall, in my opinion it is completely general in terms of making sure the result works. My point is that in terms of both simplicity (=understandability, maintenance, time for people to learn it, use it, reuse it, ....) and functionality (=getting any package to work) together, it might not be possible to beat the current system. However, one should always try, that's for sure. >>> [...] >>> I was thinking of something even simpler, where the dependent packages >>> would just be tarballs (at least as an option), so no revision control >>> is needed by the build system at all. >> >> You can download tarballs from github, for example for the Qsnake's >> cython package: >> >> https://github.com/qsnake/cython/archives/master >> >> without having git installed. So in principle the build system can use >> it too. > > Ah, yes. > >> I just stick with git for now. > > Nothing against github (in fact I really like it), it's just that I'm > wary of making my infrastructure heavily dependent on someone else's > for some things. No, you have a good point. Sage relies on the packages hosted here: http://sagemath.org/packages/standard/ or (equivalently) on the packages distributed in the source tarball, hosted here at any of these mirrors: http://sagemath.org/download-source.html So it's quite safe. I don't have many computers at my disposal, so I chose github, which allows me to upload files larger than 100MB (unlike google code). I was thinking about this too yesterday, and I think there is a *high* value in having a full source distribution, preferably with all the git histories for all the subprojects (Qsnake currently strips the .git repository from each package after downloading it from github for space reasons, but that's trivial to change), so that if the internet goes down, or github crashes, as long as enough people have downloads of the sources, there is pretty much no harm done and one can happily continue developing scientific applications, without any loss. Sage currently also doesn't have let's say the sympy git history, or Cython git history. Ondrej -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
