> On Oct 28, 4:23 am, "Georg S. Weber" <georgswe...@googlemail.com>
>> > (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
>> 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.
> the point that David Cournapeau makes is about distutils/setuputils
> too messy, too procedural, as opposed to declarative. His point about
> the need
> of a better packaging system is not about the lack of power in the
> present system,
> it's about lack of structure and abundance of general mess...
This post is about:
(1) Concern about distutils/setuptools/etc., is misplaced.
(2) Python3 and librarifying Sage.
First, all this discussion about distutils/setuptools/david
cournapeau, etc., is actually mostly IRRELEVANT to making the core
Sage library into a standalone library. The way it would work is
1. You type "python setup.py develop" (or possibly "python setup.py install").
2. A function in setup.py builds all the non-standard C/C++ libraries
that the core Sage library depends on, which is the following 24
boost-cropped givaro libm4ri mpir ratpoints
cliquer gsl libpng ntl
eclib iml linbox pari singular
ecm lcalc mpfi polybori symmetrica
flint libfplll mpfr pynac zn_poly
This function in setup.py is a Python function, and it can do
*anything* it wants. distutils/setuptools/etc. are irrelevant!! In
fact, this can just be a very simple version of the current Sage build
system, and we can just include the 24 Sage packages corresponding the
above-listed 24 libraries basically as is. Just for fun, I tried
this and wrote a sample setup.py sort of illustrating what I mean (and
ran it, and it works, but you can't, since of course it needs the
source files. I'll post more later.). When I did this, by the way,
and deleted the .a files, leaving just the shared libraries, it only
took about 25MB compressed -- pretty interesting.
3. After the C/C++ libraries have all been built, then the regular
Sage library gets built, using some slight variation of the current
Anyway, since this thread sort of ended with some major misconceptions
that the setuptools weirdness was a serious issue, I wanted to correct
Another point I think is interesting is that the Sage library itself
seriously depends on the above 24 C/C++ libraries, which have little
or nothing to do with Python2 versus Python3, plus a very small number
of Python libraries: numpy, matplotlib, networkx. Sage uses scipy,
cvxopt, etc., a tiny, tiny bit, but nothing serious. Even matplotlib
is *only* used to draw pictures. Thus if we wanted a Python3 version
of the Sage library itself, if we had a library like I describe above,
this would only require a Python3 version of numpy and networkx, plus
the work of porting the Sage library itself. This doesn't sound so
far off, since there already is a Python3 version of numpy.
To post to this group, send an email to firstname.lastname@example.org
To unsubscribe from this group, send an email to email@example.com
For more options, visit this group at http://groups.google.com/group/sage-devel