# how to organize multifile project

 6 I am working on a project to do some computations for a specialized theory. Currently, we have several files that define different objects that have various dependencies on each other. Currently, I have a file named "attachall.sage" that looks like attach "poly.sage" attach "util2.sage" attach "quasihomogeneous.sage" attach "FJRW.sage" attach "algebra.sage" etc. Then when I want to do some computations, I do sage: load attachall.sage sage: #do stuff with the objects It works fine, I guess, but doesn't seem particularly clean-- it seems like there should be a preferred way to do this. Should I use python's import? But then I would have to re-preparse every time I changed the source, and have potentially annoying bugs if someone forgot to re-preparse after changing a file. Or should I look into making a spkg? I don't really know a lot about that and I'd like to keep it simple. Eventually we'd like to be able to share this code with other groups. Does anyone have any thoughts? asked Mar 02 '11 paragon 87 ● 1 ● 2 ● 7 Kelvin Li 423 ● 9 ● 16

 5 I think if the source files are still changing, then staying with attach seems like a good idea. Once the source is stable, you can import everything using python's import -- to get this to work you just need a blank file __init__.py, and a file all.py listing what to import (maybe you don't need every function from every file). Taking a look at subdirectories of the Sage development directory will make this obvious. And you can also take a look at the python modules reference if you want, although it doesn't quite agree with what Sage seems to be doing. In the meantime, the following will also work to attach all the .sage files in the current directory (although I don't really think it's much better than what you've been doing): import glob to_attach = glob.glob('./*.sage') for f in to_attach: attach(f)  posted Mar 02 '11 niles 3354 ● 5 ● 38 ● 92 http://nilesjohnson.net/
 5 Generally, when you have done larger multi-file projects, it's easier to work directly with Python as opposed to using files that get preparsed. Python just has a better infrastructure for doing these sorts of things. There's not a whole lot of difference -- the whole Sage library is written directly in Python/Cython. Once you have the code in Python, then you can just create a Python package. There's plenty of documentation on this at http://docs.python.org/distutils/introduction.html. This primarily consists of putting your code in a folder and writing a setup.py script. You can also look at purplesage as an example of a package that does this. If you have a Python package in a directory /path/to/foo (with setup.py file /path/to/foo/setup.py, you can just run sage -spkg /path/to/foo, and it will automatically create an SPKG for you. posted Mar 02 '11 Mike Hansen 3675 ● 19 ● 43 ● 81 1 This seems a little weird to me. After going to lots of effort to make a more math-friendly dialect of Python, introducing features like (0..1) and [0..1], constructors like R., use of Sage types as the default, symbolic function definitions f(x)=x, etc., we then discourage using them beyond some point. I've wondered about this before -- http://ask.sagemath.org/question/305/importing-sage-files -- and think that Sage code should be promoted to first-class status. DSM (Mar 02 '11) I was going to say that the syntax is sage -pkg, but then lo and behold sage-sage has if [ "$1" = '-pkg' -o "$1" = '-spkg' -o "$1" = "--pkg" -o "$1" = "--spkg" ]; then. Maybe this should be documented as an option on sage -advanced, or is it a "secret" option we don't want to advertise? It's also potentially confusing since sage-spkg is what runs with sage -i, not sage -spkg. kcrisman (Mar 02 '11)

[hide preview]