[SciPy-User] Central File Exchange for SciPy

Pauli Virtanen pav@iki...
Sat Oct 30 11:51:58 CDT 2010


Sat, 30 Oct 2010 11:00:47 -0400, william ratcliff wrote:
> If we could automate it, how much do you think the bandwidth/hosting
> costs would be per month? 

No idea. Probably the traffic wouldn't be too much, at least at first.

> No bug tracking and a simple rating system for packages?

Yes.

> A section for comments about a given package.

Perhaps with a possibility to up/downvote comments?

> The submitter gives it up to 4 tags (for searching) and we
> start out with a given list of topics and let people additional ones
> later?  

Yes. It might be useful to try to follow PyPi style classifiers here, and 
extend them as needed.

> People register for an account (to reduce spam) or do we just use
> Openid or Openauth? How do we deal with spam?

Email verification on registration + spam flagging by users + 
rel=nofollow in comments?

> Do we allow people to sort packages by date? Rating?  

Yes and yes.

> Would people want to use Django?   

Django will get the job done, and it's on the easier end of the spectrum 
of Python web frameworks. I'd pick it.

> I'd be willing to purchase a domain name and pay for hosting on
> webfaction to try it out.  If it gets too pricey then I may have to
> ask for help later. (I think we should avoid ads).

One possibility might be to ask if Enthough would be interested in 
sponsoring such a thing, and running it on the scipy.org servers. But 
that's for later, when there's actually an something working to show.

> What would you guys like to call it?
> PythonCentral (is that infringing?)?  ScipyExchange?

Well, it might be worth to target it for the scientific audience, so the 
name choice should be in accord. Also, I'd avoid clone-ish names.

> If anyone wants to help mock up a prototype in Django, I have some time
> next week.  I have no design skills ;>

I know some Django.

> Finally, licensing--I don't want to start a flame war or anything, but
> can we agree to make code on the site BSD, or should we allow the
> submitter to pick an open source license.  If so, do we follow
> googlecode for the choice of license?

I'd believe allowing the submitter to pick an open-source license for 
bigger packages could be useful.

However, for code snippets we might want to enforce BSD.

> One last question (sorry for so many),  given how many people already
> have nice projects on github, sourceforge, googlecode, etc., should we
> provide an option for people to simply link to their repository rather
> than provide us with a direct copy of the code?  Actually, one model
> could be that people host their code somewhere else and we merely
> provide an aggregation service so people can easily see what's out there
> in the scientific python universe and how the community has rated a
> given package.   That way, developers can keep their existing codebases
> without changing their workflow....

Here, it would be best to not forget that we already have the scikits.* 
namespace packages, and scikits.appspot.com. How that web app works, is 
that people just upload a package named scikits.something on PyPi, and 
the portal picks it up from there.

The new system should be a "spiritual successor" to scikits, with more 
features etc., and a friendly hosting option for small snippets.

So yes, it should definitely allow externally hosted packages, especially 
PyPi. Perhaps it would even be useful to automatically import science 
packages (including scikits) from PyPi. The package entry should also be 
usable only as an "advertisement" for a package, with the package itself 
being hosted elsewhere. (Here, users should be able to flag broken links 
etc.)

Another thing that should be considered: the system should enforce that 
metadata is entered: package descriptions should be sufficiently 
detailed, a suitable number of tags should be entered, etc.

-- 
Pauli Virtanen



More information about the SciPy-User mailing list