On Jan 21, 2008 4:59 PM, William Stein <[EMAIL PROTECTED]> wrote: > > On Jan 21, 2008 1:50 PM, Soroosh Yazdani <[EMAIL PROTECTED]> wrote: > > Hi, > > > > there seems to be some exciting progress in making packages for sage. > > However, I'm curious if there is a plan for allowing normal users have > their > > own sage libraries that they can edit. That is, if a normal user runs > "sage > > -clone" on a sage that is globally installed, a copy of the cloned > directory > > will be made in his home directory, and he can edit the appropriate > files. > > And from then on, there is a hg branch that he will have access to. > > Packaging sage for distributions and your question about normal users > editing > copies of the main Sage library are orthogonal issues. The question > you raise has already been around for a long time, since very often Sage > is installed system-wide on a system (e.g., on meccah.math.harvard.edu, > there is no a new system-wide sage install, that only I have write > permission > to use). I am not aware of any plans to address this problem; generally
I agree that there are two different problems in here, but I'm not sure if you can consider them orthogonal. Although, my view of this is based on the fact that I keep on playing with the internals of sage, so I assume that everybody is doing that. As you point out at the bottom of your email, that is changing. > > speaking it is best for people to just install their only copy of Sage > in their home directory, which avoids some problematic issues > that any solution to the problem you pose would introduce. E.g., suppose > you make your own branch and start editing it, then your sysadmin upgrades > Sage without you noticing. Of course your branch won't be upgraded, > but suddenly things could (and likely should in some cases) stop working. What do we do right now if we call "sage -upgrade"? The same policy can work. > A link from where to devel/sage? You can't have > /usr/local/sage/devel/sage > point to one random particular users devel/sage. hmm, I meant the other way. I mean a soft link in the user's directory pointing to /usr/local/sage/devel/sage. Anyway, I think you bring up a very valid question. But probably the right > answer is to simply continue doing things they way we currently do. > rpm/debs/etc. are much more for people who are not doing development, > but just want to use sage. Likewise, if people are developing say pari, > they > would certainly build their own version of pari from source in their > home directory, > instead of somehow trying to develop on something installed as an rpm. > > In the not-to-distant future (and probably even now), the majority of > people > who use sage will not be editing the Sage library code directly... Keep > in mind, for example, that the great majority of Sage downloads right > now are of the vmware image for windows (there were about 1400 downloads > of Sage in the last month, and probably 30% were the vmware image). fair enough. Although, the main problem right now is that if you want to develop sage, you have to build pari, gap, maxima, atlas, ... from source as well. I look at packaging the binary as a way to ease up the building process a bit. It's hard to know how much this will help, but that's the mindset that I've had when I made the above post. Cheers, Soroosh --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
