El viernes, 15 de abril de 2016, 19:35:00 (UTC+2), vdelecroix escribió: > > 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. >
My proposal would go in the direction of having three categories: optional, experimental, and external. Optional and Experimental would follow moreless what we have now, external programs that provide some functionality, and we keep them in our packaging system because we cannot rely on them being provided by the distro (or maybe we could, but we need some patching or specific version). They are more tied to "Sage the distribution" than to "Sage the library". What I propose to call external packages would be something different. They would go in the spirit of sage/python code writen by sage users for their teaching/rsearch/whatever. In that sense, they would be in spirit closer to "Sage the library", but the Sage development team would make no promises about it (since it wouldn't go through the review process). They could be provided by any of the usual ways to install python modules (pip, easy_install...) but we could have some kind of database to do some automatic testing. We could even distribute them (as optional packages or calling them dfifferently). I think providing a template and howto for the people that wants to share this kind of code is a good start. A next step would be to maintain a database and maybe include some automated way to install them. -- 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.
