On Dec 15, 5:05 am, Volker Braun <vbraun.n...@gmail.com> wrote: > This isn't the only place where something has to be run once after > something in the filesystem changed, for example the GAP workspace and > running sage-location both have the same underlying problem
Perhaps the lowest cost change is to go with a reliable time stamp. The best I could find is $SAGE_ROOT/local/lib/python/site-packages/sage-*.egg-info which I think is the only file that is guaranteed to get rewritten by `sage -b`. So one could just save the time stamp of that file in .sage somewhere (either in a pickle or separately) and compare on startup to see if `sage -b` has been run since. This would work for both star_import_cache and for Gap (I imagine Gap could even get a better time stamp from somewhere else). It doesn't remove the redundancy that a whole bunch of .sage directories contain exactly the same cache files, but at least they're up-to-date. The sage-location thing seems different to me: Its trigger is NOT a rebuild. In fact, its action is also different. It has no choice but to write in SAGE_ROOT. Its action can be unified with the above cases by, for instance, providing a new option sage --location-and-cache-housekeeping which needs to be run after relocation and any `sage -b` (perhaps automatically?) by the UID that owns sage. Then all system workspaces and caches can live with SAGE_ROOT. That has the side-benefit that after upgrading sage a couple of times, you're not left with a lot of defunct cache files in `.sage`. (another indication that these cache files are currently living in the wrong location). > The first question would be: are we still allowing people to "develop Sage" > on a system-wide install? And how (presumably by making a copy of the Sage > library in the user's home directory)? I think that's a more complicated question. However, I do think we want to make it possible to actively develop (or at least patch!) a sage that gets run by multiple UIDs, or at least by a UID different from the UID that has write permission on the install. If a patch exists for a particularly nasty bug for a group's research, I could see how someone would want to patch a production version of sage, so that students can benefit from the bug fix. These students would need to refresh caches! Testing the notebook can similarly lead to running under different UIDs. Increasing the differences between "developing sage" and "running sage" would negate some of the peculiar benefits that sage has (getting quick bug-fixes if you need them). -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
