On Wed, Jan 16, 2013 at 2:25 AM, Burcin Erocal <bur...@erocal.org> wrote: > > On Wed, 16 Jan 2013 08:43:15 +0100 > Julien Puydt <julien.pu...@laposte.net> wrote: > > > Le 15/01/2013 23:28, Volker Braun a écrit : > > > The specialist mathematical libraries, by contrast, don't get much > > > exposure. And even if somebody packaged them then generally in > > > useless form. E.g. Fedora ships symmetrica, but its useless since > > > it is not compiled with -DFAST. Which nobody knows what it does > > > except that, otherwise, you'll get segfaults. So for all practical > > > purposes we have to build private versions of some libraries. And > > > since they haven't been written by software engineers the > > > individual build systems are generally a mess, so you can mostly > > > forget about configure/make/make install. So essentially we'll have > > > to use the current system of shell scripts to build the beast, > > > there often isn't much logic that can be shared between them. > > > > (1) Any patch to upstream should be forwarded upstream. > > > > (2) If upstream doesn't have a good build system, provide one, and > > don't forget (1). > > I agree with Julien. > > The symmetrica example shows that everyone can benefit from the testing > and packaging work done by the Sage team. I don't see how treating > mathematical software as second class can be justified because most of > it does not have a proper build system. We benefit from the code > released by the author, we should at least contribute our fixes back > and publicize them instead of maintaining our own copy. > > > Take eclib as an example. IIRC, it was John Cremona's private code > until William convinced him to release the code under GPL, and > included it in Sage. In time it got progressively better, for example > an autotools based build system and using FLINT for some functionality > (only in a development release I suppose). > > These improvements are available for anyone else to use. If eclib was > just imported to the Sage sources, I doubt if it would become such a > successful independent library. > > > Singular has quite a few examples of these too. Omalloc, the memory > manager, and factory, multivariate polynomial factorization library, > were both written independently. They were imported into the Singular > sources. Over time, the boundary between these got blurred. Now the > Singular team is spending considerable effort trying to refactor the > code to expose these as separate units.
I don't think anyone is suggesting that these dependencies get folded into our repository, but we do want to ship a tarball that includes all these dependencies (ideally pristine upstream sources that we simply unpack and invoke a build script on) so one can just download and type make. We would want to move to using a package manager to configure/install these packages, with the (overlay) spec in our repo, but this would be done spkg by spkg and not hold up fixing our workflow. Some bootstrapping logic would be required to build and install the package manager. > On Tue, 15 Jan 2013 14:51:57 -0800 > Robert Bradshaw <rober...@gmail.com> wrote: > > > > Do we really need to coordinate these? Why is Sage any > > > different from any other large software package out there? > > > > > > The standard solution to this problem is to add a "configure" > > > script to the library which checks if the dependencies are > > > satisfied and sets various options for the compilation process > > > accordingly. > > > > > > > For better or for worse, Sage couples very tightly with (and even > > patches) its dependencies, and while moving away from this is a noble > > goal I don't foresee it happening any time soon (at least I don't > > want to postpone our development model until we get there). > > Eventually the dependencies could be "see if X is on the system" > > rather than "install this (s)pkg" on a package by package basis. > > How does moving to proper DVCS based development relate to merging the > repositories? How many tickets on trac touch more than one repository? OK, here's some stats (too bad public worksheets are still disabled): sage-root: 127 out of 194 tickets correspond to a change in the sage library. sage-extcode: 478 out of 600 tickets correspond to a change in the sage library. sage-scripts: 578 out of 1235 tickets correspond to a change in the sage library. That's not including the spkg upgrades (a.k.a. dependency changes, but not tracked in any repo) that (in my experience) very often involve changes to the sage library. Also, a lot of these commits are from a long time ago before we had the habit of sticking the commit number in the patch description, so if anything it's an underestimate. Clearly this is a lot of pain for little or no benefit. > What is the disadvantage of adding "see if X is on the system" type > checks in the Sage library right now? We already do that for optional pacakges (e.g. the comercial ma*, octave, ...) It's harder to do with builds. It's also more painful to debug when not everyone has the same Sage (depending on what libraries were available when it was built.) but I think for many more packages we can do what we do with gcc, atlas (i.e. check to see if the system has one, and if not build our own copy from source). Also, tracking all this information in the main repository will make it easier to relax the strict requirements (e.g. exact versions that we build with special flags) for dependencies that are not as tightly coupled. > > > The initial design of Sage separated the mathematics library > > > from the distribution system, then further separated the user > > > interface (notebook) from the mathematics library. Why are we now > > > trying to reconcile a bunch of shell scripts with a Python/Cython > > > library for mathematics? > > > > > > > Because drawing (really, creating and then enforcing) a line between > > them is hard (it's certainly not in the right place now), and I don't > > see either one taking a life of its own without the other. Also, > > maintaining and developing on N repositories is much more painful for > > any value of N > 1. > > Sage's build system almost took life of its own in the past. Ondrej > used it for FEMHub for instance. There are quite a few projects for > packaging scientific software these days. So "life" is clearly possible > in this area. > > Merging everything in one repository would just make the distinctions > disappear over time. Making these distinctions clear is better software > practice. It would make maintenance easier over time. See the stats above. We could try to split things up differently, but I don't see any proposals that would be worth the pain. - Robert -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
