Sure, but I was thinking about something like a specific list of those pip packages that are, in some sense, tied to Sage. Where "tied" might mean several things, from "we keep a list of them in the Sage webpage" to "we ship them in Sage the distribution", with many possible intermediate points, that might or might not include the following:
- A list of these packages in the Sage web page. - Instructions on how to write, package and distribuite them. - Some kind of policy about style, reviewing and/or testing in order to be included in the list - Include the doctests in these packages as part of our testuite. - Include them in the Sage documentation - ... Is it possible, for instance, to get a list of all packages in PyPI that deppend on sage? El sábado, 16 de abril de 2016, 2:28:09 (UTC+2), William escribió: > > On Fri, Apr 15, 2016 at 4:49 PM, mmarco <mma...@unizar.es <javascript:>> > wrote: > > That is a question that we have to address: if we allow this kind of > > external packages > > It is not up to us to decide. Nobody can stop people from making > external Python packages that depend on Sage. Absolutely anybody with > any skills could read this page: > > https://python-packaging.readthedocs.org/en/latest/minimal.html > > and in about 20 minutes create a Python package that is visible on > pypi and which can be "pip installed" into your copy of Sage. (No > claims about it being useful.) As Volker has mentioned before, > everything is already in place. My hope is just that we make it > even easier than it already is, and actually everybody is doing that > right now :-) > > > (or furthermore, move the devlopments of parts of sage to > > a different workflow)... what kind of control will we do about them? > Will we > > make no promises about them at all? Have some kind of revision process > > before accepting them? If so, what exactly do we check? > > > > The fact that all Sage code goes through a peer review process is an > > important point. So, if we split the development process in different > > modules... should we enforce such a review process in all the modules? > > All sage code that we distribute as part of the Sage library goes > through review. > That's not the case for "all sage code" though, in the sense of code > that depends on Sage. > > It might be worth thinking about this like the difference between > "writing a paper and putting it on arxiv" and "publishing a paper in a > top journal"... and your questions are also extremely good questions > for the "publish a paper" setting. Erik Bray shared his experiences > about "affiliated packages" for his previous project... > > -- William > > > > > El viernes, 15 de abril de 2016, 23:40:05 (UTC+2), Dima Pasechnik > escribió: > >> > >> > >> > >> On Friday, April 15, 2016 at 10:13:22 PM UTC+1, Simon King wrote: > >>> > >>> On 2016-04-15, Vincent Delecroix <20100.d...@gmail.com> wrote: > >>> > +1. The need of modifying Sage source code to have an external > package > >>> > is very bad. > >>> > >>> I miss old-style packages, too. > >> > >> > >> we didn't get to see an spkg with a virus or with `rm -rf /`, but > surely > >> it was just a question of time... > >> > > > > -- > > 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+...@googlegroups.com <javascript:>. > > To post to this group, send email to sage-...@googlegroups.com > <javascript:>. > > Visit this group at https://groups.google.com/group/sage-devel. > > For more options, visit https://groups.google.com/d/optout. > > > > -- > William (http://wstein.org) > -- 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.
