On Mon, Nov 1, 2010 at 7:34 AM, leif <not.rea...@online.de> wrote: > On 1 Nov., 07:51, William Stein <wst...@gmail.com> wrote: >> 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. > > That's an argument (honestly). Distutils/Setuptools is broken (or > weird), so we don't [have to] use it. > Not very "pythonic" though, I guess... ;-) (but nobody should be > forced to drive with broken wheels)
I don't quite agree with this interpretation. Even if setuptools/distutils were "perfect" they would not be the right tool for building those 24 libraries. The right tool is a Python script that calls the native build system on each of those 24 libraries (e.g., which is autoconf, perl, etc.). > > >> [...] >> 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 >> [...] > > I'd prefer having plain text files rather than a pickled build_db. Thank you for looking at the code. It is just a pickled pure python dictionary, which is flexible and easy to work with. > Adding (formal) dependency specifications to the spkgs (a file, say, > spkg-deps in each spkg) would be a step forward, too, such that we can > also *generate* the "real Makefile" spkg/standard/deps in the > traditional build process. There's no deps file in what I'm doing. Also, among these 24 libraries the dependencies are nearly trivial. Basically, many depend on MPIR, some on NTL, and beyond that there is nothing (?). > (In addition, a lot of what's currently performed in every spkg- > install could be factored out.) True, but orthogonal. > > > -Leif > >> [...] 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 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 > -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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
