>

>

> On Oct 28, 4:23 am, "Georg S. Weber" <georgswe...@googlemail.com>

> wrote:

>> > (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

> getting

> 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

this:

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

libraries:

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

build scripts.

---

Anyway, since this thread sort of ended with some major misconceptions

that the setuptools weirdness was a serious issue, I wanted to correct

this misconception.

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.

-- William

--

To post to this group, send an email to sage-devel@googlegroups.com

To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com

For more options, visit this group at http://groups.google.com/group/sage-devel

URL: http://www.sagemath.org