Hello William, On 20 February 2015 at 01:22, William Stein <wst...@gmail.com> wrote: > > This has been discussed over and over again and it plainly doesn't > work. The Sage in Debian does not pass doctests, not even close. In > general the combinatorial explosion of configurations to debug is way > too large and it is next to impossible to find any distribution where > the version numbers even remotely match. We updated to GAP 4.4.12 in > Sage 3.3 and the doctests involving GAP will in certain files be > broken with any previous GAP release. If you used the Debian packages > for Singular Sage won't work since we patch NTL and when those NTL > libs come in conflict either Sage doesn't compile or Singular blows > up. I can go on and on and on about similar issues and that is only > the stuff I know about right on top of my head. I have never taken the > time to go out and do dumb things to break Sage :) > > In the near future we plan to upgrade to a svn release of the > development version of pari and then closely track it as bugs we > report are often only fixed in pari-2.4.3svn. There is *no* way any > distribution can track this without potentially breaking other code > dependent on pari and you will be royally screwed if you want to use > pari 2.3.4 in Sage (the stable release at this point) since Sage won't > even build. We will fix all in tree code that gets broken with the new > pari-svn and push it back upstream, but until that shows up in a > distribution we will long have shipped Sage 4.0. > > The way we do it is the only way and I have doubts that any > distribution packaged Sage will even be able to keep up with the > official release given that I (=Michael Abshoff) spend working full > time as the Sage > release manager :)"
With due respect, all these points indicate software engineering deficiencies (e.g., the inability to guarantee a stable API, variations in the results of identical commands from one version to another, etc.). > Those are a different domain of software engineering. Mathematics > software is fundamentally different than word processing, graphical > desktop, and web browser software. It doesn't matter much if a line > in a UI is off by one pixel. In mathematics, being off by 1 can > result in major bugs all over Sage. > I disagree with this argument. Mathematics software is exactly the same as any other software. I am pretty sure that off-by-one errors are taken pretty seriously, e.g., in the Linux kernel, in GCC, Glibc, Python or the cryptographic code in Firefox or Chrome. Also, your statement here seems to be at odds with he paragraph above, where Michael laments that changing the versions of software changes the result of computations? The point was about handling long dependency chains (so I picked as examples a bunch of projects with a long dependency list). Why is it that I can expect to be able upgrade seamlessly, on my linux box, a library like libpng or openssl - on which hundreds of other packages depend - without breaking any of them? Again, this has only to do with software engineering best practices. > The Sage distribution model, which has frequently been attacked every > single year for nearly a decade, is one of the most important reasons > for Sage's success. > Still, after ten years it is still not possible to do "yum install sage" or "apt-get ... ". I would say that this is a barrier for a lot of people to use sage. > That said, if somebody had the energy to make and maintain a > branch/fork of Sage that could easily integrate with Linux distros, > more power to them. I'd be happy to host it, point to it on the sage > website, etc. If I had infinite resources (money) I would definitely > hire somebody to create and maintain such a thing. It wouldn't even > be a question. The problem is that right now we have *extremely* > limited resources and have to make choices. > In all honesty, I think you should throw golden bridges to people like Julien and Francois who are doing all this heavy-lifting work on the software engineering side of things. I think that having sage integrating with distro packages would not only be a benefit from the point of view of expanding the userbase, I think it would also greatly increase the software engineering quality of sage and related packages. Cheers, Francesco. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
