I do know I can solve the problem for me if I modify my private "~/.sage/sagerc" file. However, I intend to create a "spkg" for that "package" and advertise the usage of sage among people who use that "package" now (especially these who use it with python now). I can tell them they simply need to "./sage -i package.spkg". but if I then tell them that each of them is also expected to add a whole bunch of lines into their private "~/.sage/sagerc" files ... how many of them will still be interested? And of course if they installed another tools they must "manually" make sure that everything gets initialized in a specific order ... Moreover, what if any "future" version of a particular "package.spkg" needs somehow different initialization ... each user is expected to immediately know it and keep track of it in the "~/.sage/sagerc" file? Think about "administrators" who "maintain" some local "notebook" web servers. I can convince them to say "./sage -i package.spkg", but do you really think they will want to modify their system-wide "sagerc" files? In long term, I really believe, sage needs a mechanism of "run-time" initialisation of packages. Currently such initialisation is really performed in the "sage-env" file, but only for packages that are "officially" included in sage and there is no straightforward way foreseen to add initialisation of "optional" / "additional" packages.\ Why not add my proposal to the standard sage? It's fully backwards compatible. It doesn't break anything. It simply introduces new features.
-- 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 http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
