On May 18, 6:17 am, Kevin Horton <khorto...@rogers.com> wrote:
> On 18 May 2009, at 02:02, William Stein wrote:
<SNIP>
> Will packages created for SPD be usable as-is in Sage, or will they
> need to be tweaked in some way before they can be used with Sage?
Yes.
> Will there be some sort of automatic installation of package
> dependencies? This would seem to be highly desirable.
I have the desire to fix the dependency problem. i.e. each spkg should
describe its dependencies and we should then use a little script to
turn that into a dependency makefile. The main problem to do this are
at the moment:
(a) we need to agree on a standard, i.e. file naming conventions, etc
(b) we need to come up with a central spkg repo, i.e.
spd.sagemath.org ;)
(c) we probably will need the concept of meta-spkg, i.e. Fortran
would be one obvious thing where various possibilities arise.
(d) we also need something like a number of toggles, i.e. FRAMEWORK
build on OSX would be one, so if you wanted Mayavi on OSX the build
system should be smart enough to force a framework build on OSX.
(e) minium and maximum version numbers of spkgs allowed, i.e. in case
you have build issue or bugfixes mandate minimum versions, security
fixes, etc.
None of the above is particularly hard to do, someone just needs to
find the time to do it. We should very much orient ourselves toward
the Debian build system, but obviously we cannot use it since we want
to be truly cross platform.
What this very much goes into is the ability to to custom Sage or SPD
distributions, i.e. you could specify a profile like
[profile]
require: sage-fe
require: sage-notebook
[end profile]
and then a little script could spit you out a tarball for your
specific purpose that would have all the dependencies resolved. In
this case it would obviously contain all the bits required to build
the notebook and the packages considered to be part of a not yet
existing finite element set, i.e. some of the stuff Ondrej & friends
are doing.
This would also allow Sage to more or less get rid of most
experimental and optional spkgs and just release them in a pool of spd
maintained packages where hopefully upstream would take care of
maintaining them. Obviously a log of current Sage devs would then keep
taking care of optional and experimental spkgs.
Cheers,
Michael
> --
> Kevin Horton
> Ottawa, Canada
--~--~---------~--~----~------------~-------~--~----~
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
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
