On 1 Nov., 17:16, William Stein <wst...@gmail.com> wrote: > 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.).
Well, if they /were/ "perfect", one could perhaps use them for such as well. (Developers, either upstream or we, could also ship a setup.py or similar as an alternative to "configure/make/make install" or spkg- install. I first thought you also aimed at the latter.) My point was it previously wasn't clear to me that you intended to keep / use the spkg-install scripts of the spkgs. > > 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. Easy to work with from Python. I like having human-readable (and writable) configuration etc. files in a format that's pretty generic to be managed / processed by shell and other scripts / programs as well. But that's UNIX philosophy. (And I didn't mean XML.) > > 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. I guess /not yet/, since I think it is a prototype. > Also, among these 24 > libraries the dependencies are nearly trivial. Basically, many depend > on MPIR, some on NTL, and beyond that there is nothing (?). :-) No reason to hard-code them, especially if we could use such deps elsewhere, too, even for documentation. And as always, they are subject to change. Having them attached to the spkg files rather than in a manually maintained, separate "global" file (currently not even under revision control, cf. #9433) is less error-prone and aids modularity. > > (In addition, a lot of what's currently performed in every spkg- > > install could be factored out.) > > True, but orthogonal. Yes, but (IMHO closely) related, to "both ways" of installing Sage. -Leif -- 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
