> You are making several assertions > > 1) Sage source code is of good quality > 2) We do not test "external packages" > 3) Adding and maintaining source code in Sage is simple > > Let me discuss them in order. > > In my opinion, the most powerful part of Sage comes from its third party > libraries (such as NTL, flint, pari or singular). The Python user > contributed code is often slow and of bad quality compared to the 4 > mentioned libraries. >
These are packages we have built upon, not that are built upon Sage. So this is completely unrelated to my point about the code quality of Sage. > > Let me add cypari2 [1]. This used to be code inside Sage and it is now a > project on github (and also a standard Sage package). cypari2 can be > installed in a standard Python installation. and is tested on a regular > basis within Python2, Python3 and Sage. Since it is an independent > project, its doctest coverage is actually better! > Again, cypari2 was not really built upon Sage, but instead something that should exist as a standalone project that Sage could then build upon. So this is a non-example. > > The code quality is up to the project developers and not the consequence > of the peer review process that we have in Sage. The only advantage I > see in this process is its friendlyness (it helps users to become > developers) and the helpful automated doctesting. > > I am assuming by "this process" is the Sage peer review. It also does usually improve the quality of the code and the documentation. It also means that we only need to have one release manager who merges code into master. > > The examples that I developed above concerned somehow the "kernel" part > of Sage and not specialized code that a researcher is likely to develop > for her purpose. Let me use the same example as you did: the statistics > software R [2]. They have a database of ~10000 external packages that > are tested on a regular basis. I don't see why this is something we > could not afford in Sage. pip does support installation/uninstallation. > It would be simple to pick the packages one by one and use a patchbot to > test them. > > That is precisely what could be a problem. Doing things one-by-one means you may not see how one dependency affects another. Also, what are the rules? If B is based on A, do we require that A does not break anything in B or is B responsible for any downstream changes in A? If it is the former, then you have a useless extra layer because there is no point in have separate modules. It is functionally acting as one complete unit. If it is the latter, then there is no guarantee that stuff will not break. However, what quality control measures does R have in place? Does it arbitrarily allow packages to break? What do they do with dependencies? How much duplication do they have? IIRC, they also have better tools in place for package management; something we would need to do develop if we decided to break Sage up into little bits and pieces. > > For the last point, including code in Sage is dependent on reviewers. > Since this is on a volontary basis, some important tickets get ignored. > Because too technical, because of lack of time, ... On the other hand, > some code gets included too quickly. We now have a huge amount of code > that is a pain to maintain. There are some bugs that are pending since > many years and are note likely to be solved in the next future. Each > time Sage grows it makes it harder to have them fixed. > > How much of that code is really a maintenance burden? Would any of those bugs actually be fixed if you go to external packages? How many of them would actually be found, much less reported (to the correct place)? If code being included too quickly is a problem, then why are you suggesting a method to include code even faster with less QC measures? > > As a conclusion, I would be much happier with > > 1) A Sage kernel as small as possible with strictly specified API and > slow release cycle. > > 2) External packages registered in a database and tested on a regular > basis by patchbots. The release cycle is to be decided by developers. > By "developers," you mean the external package developer(s)? You need to specify what rules you want in place. Nobody has yet to actually specify anything like this. Best, Travis -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
