On Thu, Oct 28, 2010 at 11:02 PM, Dima Pasechnik <dimp...@gmail.com> wrote: > > > 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
setup.py
Description: Binary data
