On Fri, Apr 15, 2016 at 8:04 PM, mmarco <mma...@unizar.es> wrote: > 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.
+1 I think this is in the right direction. And I think that some of the existing leaf packages of the core sage-lib could be re-distributed in this form. But as Vincent has repeatedly written it would be more important to have this infrastructure and process in place than it is in most cases to decide specific things to *remove* from sage-lib. Even though I think there are things that should be split out I could agree it's not as urgent to do so, and it should be handled with great care. This is Astropy's "database" of affiliated packages (similar to what you're calling "external packages"): https://github.com/astropy/astropy.github.com/blob/master/affiliated/registry.json I've argued a few times (but without much action on my part) that it should be more detailed, including summaries and separate detailed descriptions of the packages' contents, links to their documentation (which is sometimes different from their home page) so that their objects.inv can be downloaded easily for inter-sphinx, and possibly even the commands to run to build, install, and test those packages (in most cases these are the same since most of these packages use a template that provides all these features). Erik -- 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.
