>
> (1) Have a Python library called "sagecore", which is just the most
> important standard spkg's (e.g., Singular, PARI, etc.), perhaps
> eventually built *only* as shared object libraries (no standalone
> interpreters).
>
Interesting!
One challenge I see here, is that on the one hand, Python is pretty
agnostic to the OS resp. system it lives on. This has both advantages
and disadvantages. It's good for everything "pythonic", but there are
quite essential parts of Sage that are (or rely on) C/C++ libraries.
Building these is sensitive to the OS resp. system, and the "classic"
setuptools/distutils are ill suited to handle this (except if such
libraries are already provided as binaries ...). The situation gets
even worse taking Cython into account, whenever Cython code relies on
some external C (or C++) libraries (dependency/library version
checking, or think of "#clib" and friends). But even "pure Python"
code is problematic, as soon as some external C (or C++) libraries are
needed (PIL e.g. "just" needs libtiff, libjpeg, ... I certainly do
remember it to be troublesome).
The SciPy/NumPy project is in a quite similar situation. David
Cournapeau, the maintainer of NumPy, has written up some details of
this challenge in a blog post last year:
http://cournape.wordpress.com/2009/04/01/python-packaging-a-few-observations-cabal-for-a-solution/
Don't get mislead by the name of the link, the outcome is a (still
work in progress) build system he named "bento", see:
http://cournape.wordpress.com/2010/10/10/bento-0-0-4-released/
I just can't believe David Cournapeau would go this way, if "python
setup.py install" could do "anything", or if Python resp. its ecosysem
(PyPI, ...) already had reasonably good support for the needs of the
NumPy project.
However, the idea of having "layers", explicitly a "sagecore" Python
library, on top of which sits the "sagestandard" Python library, on
top of which (or at its side) may sit some research "psage" Python
library, is IMHO a valuable one, worth of pursuing further.
Essentially, it's a matter of slicing the current rather monolithic
Sage distribution into reasonable peaces (whatever "reasonable" might
mean in this context ...).
Cheers,
Georg
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
