On 15/04/16 14:18, mmarco wrote:
I would consider graphs to be part of the core. There are many other modules that deppend on it. Maybe it could be split in two parts though.
I still consider that where to split should not be part of the current discussion.
I think one of the problems to be addressed is that we lack a system to have "external packages". We do have "optional packages", but that is another history, since they go through the usual development process. One has to write the corresponding scripts, open an account in trac, open a ticket, and wait for it to be reviewed, this stops a lot of people. We would need something simpler for people that just wrote a few functions to compute something related to their research, and want to share them with others.
+1. The need of modifying Sage source code to have an external package is very bad. Moreover, it does not give any guarantee that a given optional package is actually working (beyond the fact that some people actually uses it). So this is about:
* how to completely externalize existence of optional packages (Python packaging/library is one way already in use)
* how to integrate in the patchbot testing optional packages (see #20182 in that direction)
But on the other hand, if Sage core has no idea about the list of packages, how could we test them? Would make sense to have somewhere a list of packages together with a classification along:
- link to tarball broken - does not build - does build but have not test suite or test suite fails - does build and test suite succeeded The current optional vs experimental reflects this a bit. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
