how to organize multifile project

Question

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?

Accepted Answer

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)

Answer 2

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.

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.<x>, 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)

how to organize multifile project

2 Answers:

Your answer

Question tools

Tags:

Stats:

Related questions