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.
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!
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.
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.
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.
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.
[1] https://github.com/defeo/cypari2
[2] https://www.r-project.org/
On 25/07/2017 08:43, Travis Scrimshaw wrote:
I disagree with the conclusion of Marc's slides; in particular that it is
the "right way". In fact, I am going to be bold and propose that only
adding new code like that is the wrong way for developing Sage. Following
the logic, we should take all of the code in Sage, put in into (separate)
3rd party packages, and have Sage be the bindings between some of the base
dependencies. However, these different parts of Sage can have very
non-trivial dependencies and local doctests do not necessarily have.
Moreover, there is absolutely *no* quality control measures put in place:
anyone can put code in a 3rd party package with little-to-no documentation
or doctests. So code is likely to break, not work, and/or be unusable. That
really is the only advantage I can see to having a 3rd party package: you
do not have to do Sage's review process.
Now, for distributing code with the eventual goal to merge into Sage, this
is a good methodology. However, it still does not replace a good trac
ticket with code that should be there for people to review. Additionally,
if you do all of the stuff to bring it to Sage's standards, how much harder
is it to submit it as a trac ticket for integration into Sage? If it
languishes in needs review, then users can use it (and hopefully one of
them will eventually review it, but that seems unlikely). We also do not
have the infrastructure to do something like R with package management. IDK
what QC measures R has in place to fairly assess their process.
In case it was never mentioned here, there is also a large list of
external sage-dependent packages here:
https://wiki.sagemath.org/SageMathExternalPackages
<https://www.google.com/url?q=https%3A%2F%2Fwiki.sagemath.org%2FSageMathExternalPackages&sa=D&sntz=1&usg=AFQjCNFVe1YmfRWENzfRockIeaZD5qCY7w>
Case in point, how many of those external packages actually work with 8.0?
Is anyone actually testing them? SageManifolds has now been fully
integrated into Sage proper, so it probably should not be on the list. I am
suspect that a number of them will work on 8.0 due to internal changes in
Sage. Train tracks are now in the process of getting merged into Sage.
--
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.
