>
> 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
...
> ---
>
> 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.
Yes,
there were some misconceptions. My concern is that maintaining the
ability to build all these 24 C/C++ libraries currently is quite some
effort: on quite a variety of systems, with several toolchains, with
$SAGE_ROOT as prefix, and all the necessary patches here and there ...
And new OS versions do come out (Fedora 14, OS X 10.7, OpenSuse
12.0, ...), as well as new versions of one of these 24 libraries
themselves every now and then.
Thanks for posting the "setup.py" script, it clearly illuminates that
we were talking at cross-purposes (I hope I looked up that wording
correctly :-)). I think it has become clear now, that without some
help of tooling (scripts, or whatever), the situation will only get
worse (Leif already pointed out issues). Why not "outsource" this
business, including the tooling itself? Then the "build_package()"
function in your "setup.py" would essentially just be a one-liner:
emerge name
(using ebuilds and portage from Gentoo) or maybe, say
pacman name
(using pkgbuilds and pacman from Arch Linux), and e.g. inter-
dependencies would be resolved automatically. Using a such a full-
grown tooling for "just" 24 packages (i.e C/C++ libraries) might seem
overkill at first sight. But I don't think so, to the contrary, the
overhead (portage e.g. is less than a megabyte compressed) is pretty
low, and to me, seems well worth it. (And I hope we can agree that
setuptools/distutils is not suited for this.)
But that should deserve its own thread, so I stop here.
>
> 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.
>
I'm all for slicing up the current rather monolithic Sage distribution
into smaller, more manageable parts. Having an independent "Sage
core", the transition to Python 3 will certainly be less painful (the
question is not whether, but only when we'll do this). It is even
thinkable to have some parts using Python 3 (the Sage core, say) and
some parts still using Python 2 (SageNB? or which parts of the Sage
distribution were relying on that old version of Twisted?) at one and
the same time, even in officially shipped distributions ...
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
