[SciPy-User] Central File Exchange for Scipy

[william ratcliff]

Check out apparmor..
On Apr 19, 2011 5:25 PM, "Pauli Virtanen" <pav at iki.fi> wrote:
> On Tue, 19 Apr 2011 15:27:40 -0500, Jason Grout wrote:
>> On 4/19/11 2:00 PM, Pauli Virtanen wrote:
>>> Since a DVCS would not be exposed to the outside of the application,
>>
>> I think it would be really nice if the DVCS was exposed to the extent
>> that someone could git/hg clone their snippet/package repository and
>> move it to github/bitbucket once it became a bigger project. On the
>> other hand, I can imagine some people wanting to work locally with their
>> package repository and then push to the server. I don't think we need
>> to do a gitorious/github/bitbucket rewrite, but having a way to get your
>> repository off the server or push to the server would make it much
>> easier to transition projects that grow larger.
>
> I think we have a slightly different ideas of what we are trying to make.
> Maybe it would be useful to try to clear up the aim before going to
> nitty-gritty :)
>
> My idea was to get something like Wikipedia or ohloh.net centered on
> scientific Python software. So the focus would be mainly on "released"
> software, rather than being a platform for software development, such as
> Sourceforce, Gitorius, or Gists.
>
> Allowing file and cookbook page hosting would then be just a side
> feature, just for convenience for the people who are too lazy to learn
> how to use bitbucket and other tools properly. In this view, use of DVCS
> is out of scope. Joint development would be diverted to the "traditional"
> channels when possible --- direct communication with the original
> authors, or whatever community site they use to share their work.
>
> Whether this is an useful target, is of course up to debate.
>
>
> Pros:
>
> + simple to implement
>
> + puts more weight to "finished" and (hopefully) more useful works
>
> Cons:
>
> - does not especially encourage collaboration
>
>
> ***
>
>> I notice you have three categories of entries according to the
>> DESIGN.rst. Here are some design questions/comments about each:
>>
>> 1. Hosted software-Code submitted by people directly to this site.
>> Edited by the original submitters solely.
>>
>> - It would make sense to allow multiple people to commit to a package,
>> if it's easy. If it's not, then I suppose we encourage projects that
>> need more group-aware tools to use github or bitbucket or something and
>> instead just link to their repository.
>>
>> Having a very simple "forking" feature would also be nice.
>
> My view would be that we only want more or less "finished" works to
> appear there. If so, the catalog does not really need features related to
> software development --- except maybe a link pointing to where the
> development is ongoing.
>
>> 2. Pointers to externally hosted packages, hosted on PyPi, github,
>> bitbucket, someone's homepage, etc. Editable by anyone.
>>
>> - Editable by anyone worries me---these are like the grown-up versions
>> of (1), so it makes sense that the original submitter is the one to
>> update these.
>
> Being editable by anyone makes sense if you think of this part as a
> Wikipedia/ohloh.net of scientific Python software.
>
> The main issue here is that it would be useful for other people to be
> able to also add links to projects you aren't an author of, improve
> incomplete or terse descriptions, etc. Note that these type-2 projects
> do not have any hosted code.
>
> The criticism on enabling vandalism and spam is a valid one. Dealing with
> it requires an adequate reversion & change monitoring UI, and enough
> manpower. As a middle way, the changes could of course be moderated
> manually, so that they appear only after approved by a group of editors
> (and/or the original submitter).
>
> But in any case, retaining the ability for anyone (registered) to submit
> corrections to these catalog entries seems quite useful to me.
>
>> 3. Short code snippets and code examples. Public domain and editable by
>> anyone.
>>
>> - Sounds good, though I'm ambivalent about whether these should be
>> wiki-style or gist-style (e.g., editable by anyone, or forkable by
>> anyone).
>
> The aim with these "snippets" was mainly to replace what's currently in
> scipy.org/Cookbook, rather than to build a branded competitor to Gist or
> similar services. Wiki-style seems like a useful choice here to me (and
> my calling them "snippets" was a bad choice of words --- they're not
> really the same).
>
> The aim that I had in mind would be more to get an organized collection
> of useful recipes with explanations how things work, rather than a
> collection of miscellaneous code snippets "owned" by different people.
> Wikipedia vs. Knol...
>
>> These are the sorts of things I envisioned having an "execute"
>> button on that would send the code to a server, execute it, and post
>> back the results.
>
> Needs some serious sandboxing on the server side. Sage seems to manage to
> do this, though.
>
>> Finally: which pieces do you envision having a version history exposed
>> to the user? Do you envision a "forking" or "branching" action for any
>> of these?
>
> The version history exposure would be essentially what you get in your
> average wiki. You don't normally look at it, unless you want to revert
> something.
>
> Forking and branching is out of scope, since the focus is on released
> "products" rather than their development.
>
> Pauli
>
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20110419/5ade19c5/attachment.html>