On Friday, April 15, 2016 at 11:04:37 AM UTC-7, mmarco wrote: > > > > 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. >
Would it also be possible for them to be installed either in the main Sage directory or in the user's .sage directory, depending on how the installation was invoked and/or permissions? Pardon my ignorance, but how does Python deal with this? John -- 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.
