On Mon, Nov 26, 2012 at 11:48 PM, Burcin Erocal <bur...@erocal.org> wrote: > On Tue, 27 Nov 2012 01:53:31 +0800 > P Purkayastha <ppu...@gmail.com> wrote: > > <snip Robert's post> >> I think the Sage community could quickly expand and there could be >> tens, if not hundreds, of git development branches once the switch to >> git occurs. It would be quite hard to keep track of all the different >> branches and the individual modifications that people have in their >> forks. I looked up scipy right now, and that itself has over 500 >> watchers and 200 forks. The situation is the same for matplotlib, and >> almost the same for mathjax. It would be nice to see how those >> communities cope with such a huge number of forks and development >> branches. > > Note that most of the research code we are talking about is either a > single .sage file or a bunch of .py files in a directory, totaling > at most 1500 - 2000 lines of code. Here is a good example: > > http://math.bu.edu/people/rpollack/OMS/OMS.zip > > from http://math.bu.edu/people/rpollack/
Or https://github.com/haikona/OMS for what that very code has evolved into... in the process of trying to to get it into Sage (via workshops, student projects, etc.) > > > I cannot imagine research mathematicians wrangling forks of the Sage > library (IIRC, ~ 500k lines of code) just to get a small piece working. > In most cases, these forks will contain old versions, untouched since > the paper was published, so even merging with the latest Sage release > will be nontrivial. Especially if the research code required changes in > some core Sage library class (add a function to number fields say), only > a few people really familiar with Sage (and the DVCS system in use) can > handle the merge. > > This is all to say that git forks are not going to solve the problem > Robert brought up. I don't follow you. For example, you say "only a few people can handle the merge". If I fork the sage repo (on github say) today and do nothing to it, then try to merge with sage in 6 months, the merge would be automatic/trivial (as long as the history of sage moves forward). If I make a few changes, merging will only involve those changes. Of course, as you say below, I agree that making separate Python packages for individual projects is a reasonable way to go. This is just the analogue of R packages, or npm modules (in node), etc.,... or even PyPi (http://pypi.python.org/pypi). I wonder if people could in fact post Python modules on PyPi that depend on the Sage library? >> What I describe below is one way I think we could have access to the >> many individual patches and "alpha-quality" code people might have. > > Here is another way, which is not at all new. :) Do what William does > with psage: > > If your code exceeds the "single .sage/.py file" threshold, it is > fairly easy to create a Python package out of it. With the myriad of > Python packaging solutions (easy_install, pip, etc.), installing such a > package given a URL is also trivial. So just publish the URL on your > home page, announce it to your colleagues and you're good to go. +1 > There are several problems with this approach, which I mention below. > >> To encourage people to contribute back high-quality version of their >> research projects into Sage, one thing that could be done is to >> enable a wikipage where the developers can mention or list their >> current project/unpolished code. The hope is that such a model will >> help the person get feedback for his/her code and the person can get >> encouraged to eventually submit it to trac and include it with Sage. >> It often happens with me that I get a bit more motivation to >> finish/polish my work once someone asks me for it - the feedback >> helps me know that the code might be useful for someone else too! I >> wonder if other people here have faced similar situations. > > The wiki page is a good idea, but it would be filled with stale > information quickly if it is not supported by some infrastructure to > keep it up to date. > > You're right that getting feedback is a great encouragement to polish > the code (which is a big advantage of the combinat model), but I don't > see why it also encourages people to submit it to Sage. The review > process can be quite painful after all (see #9016). In many cases, from > a professional/career perspective, this is even bad for you: > > * once your code is readily available in Sage, people assume it's > standard functionality and stop citing/giving credit to the > implementation/paper > > * the time spent to polish the code is wasted according to academic > assessment criteria, which usually only counts publications and > citations > > > We tried to address these problems to provide more of an incentive to > make people submit their work to Sage with the citation module: > > http://trac.sagemath.org/sage_trac/ticket/3317 > > Here is some relevant discussion from sage-devel more than a year ago: > > https://groups.google.com/d/topic/sage-devel/RtYTIxgn2io/discussion > > > Going back to the problems with individual packages: > > - code that is not tested regularly against updates in Sage bitrots > > This problem can be solved by a continuous integration system (like > patchbot) that runs the tests against changes in Sage. Depending on > hardware availability, this can happen with every beta and rc > releases, or even daily. > > The developer has to commit to fixing the problems revealed by the > test suite. This would be in their interest, since it guarantees > that if somebody else ever wants to use the code in question, it > will (up to amount of test coverage) run on the latest Sage release. > > - some research code goes beyond just a bunch of python files. > > For example Simon's p-group cohomology package: > > http://sage.math.washington.edu/home/SimonKing/Cohomology/ > > It includes MeatAxe, a C-library, and depends on an optional Sage > package. This provides a challange to Salvus (or wakari: > http://continuum.io/blog/introducing-wakari) like models. Unless > they create a virtual machine for each user to play with, I don't > see how they can support installing arbitrary code. I will (at some point) for Salvus. > Package dependencies for optional/experimental packages is beyond > the capabilities of the sage packaging system. Adding > "sage -i <package_name>" commands to spkg-install is a very ugly > hack. What's the situation with Pypi or any other Python packaging solutions. Surely they provide dependencies? > > > If you've read so far, maybe some self-plugging will be tolerated. > lmonade (http://www.lmona.de/) is designed to solve these problems, > with > > - a flexible package manager that support overlays and > > - a continuous integration system (patchbot in software engineering > speak) where people can sign up to get their code tested when the > packages they depend on are updated. > > It still lacks many features due to lack of developer time. I plan to > change that soon (also encouraged by discussions like this one), but > any help is much appreciated nevertheless. > > > Cheers, > Burcin > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To post to this group, send email to sage-devel@googlegroups.com. > To unsubscribe from this group, send email to > sage-devel+unsubscr...@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel?hl=en. > > -- William Stein Professor of Mathematics University of Washington http://wstein.org -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
