[SciPy-Dev] SciPy Central in GSoC 2013

[Andreas Hilboll]

>     > The proposal (draft) is
>     > here http://surya-gsoc2013.blogspot.in/2013/04/the-proposal.html
>     > It would be great to hear some comments, suggestions etc.
> 
>     Just as a side note: Each item should have module versions in the
>     metadata, as in "works with numpy1.6, scipy0.10, pandas0.9". Also, it
>     should be possible tó flag items as "doesn't work" or "doesn't work with
>     current (which?) modules".(This might be a good example for where
>     hierarchical tags would be useful).
> 
>     - Andreas.
> 
> 
> This helps a lot for users.. the below are the couple of ideas I got in mind
> 
> 1. users should be strictly directed to add these details in the snippet
> documentation (not all might do)
> 2. we need to detect the modules used in the snippets, ask them to
> provide versions for them during submission
> 3. (instead of 2): we can ask them to attach "requirements.txt". this
> should be quite good and simple way to handle things..
> 
> /Detecting the modules/ in the snippets, adding them as tags for
> improving search is one of the possible feature I mentioned in proposal
> (at the bottom of the page)

I think this is a whole sub-project in its own; I can identify the
following parts:

a) Figure out the data model / workflow to use
b) Implement simple input form for the submission/revision
c) Add module auto-detection and use the results in the display of b.

As for a), I can envision several ways to deal with this:

   1. The author enters the requirements
   2. Users have the possibility to add information like "works/doesn't
      work with thisandthat module versions"

The nice thing about 2. is that even if something breaks due to API
changes in the used modules, a user would have the possibility to flag
the item as "doesn't work as-is", making it easy for other users to
check out such issues.

So here, we need to decide on which way we want SPC to work. Then, this
workflow can be put into the data model.

In the beginning, it would be enough to have b) because it would allow
using this feature. c) is definitely a nice-to-have, but it's
essentially useless if a) and b) isn't implemented correctly.

-- Andreas.