Community apps and backends on the new rapidsms.org site

[Colin Copeland]

Hey,

We're in the early stages of development on the new site and I wanted to poll the list on a specific section of the spec: Packages. This section of the site will list all user-contributed RapidSMS community apps and backends that have been submitted. In an effort to standardize RapidSMS packaging and follow the Python norm, we want to stress the importance of publishing your pluggable apps and backends with a setup.py file, on PyPI, etc., and move away from no setup.py and git submodules.

So my question is: how would you all feel about only listing packages on PyPI?

The two options are:

• Only PyPI: Anyone can add a new package to track. We have a scheduled task that periodically scans the added packages on PyPI via its API. All meta data is puled from setup.py. No permission issues of who can edit. We always list the latest version.
• GitHub + PyPI: Same as above, but you can also list a repo URL. You enter data manually. Allows listing of apps/backends not on PyPI. Only editable by the user who added it.

I think PyPI-only is the easier option, but I wanted to see what everyone else thinks. Let me know your thoughts!

Colin

--
Colin Copeland, Managing Member
Caktus Consulting Group, LLC
http://www.caktusgroup.com

[Dan Poirier]

S

​hould we require packages to be on PyPI in order to be listed?

I think it depends whether we're more concerned about making information about useful packages available to RapidSMS developers, or encouraging package writers to follow Python packaging conventions.

​Maybe we could allow submitting non-PyPI packages, but in a very limited way - just a link and a description, and no attempt to provide any other metadata about those packages. That way  at least developers looking at the site would learn that the package exists. If they think it looks useful, they could also encourage the package owner to publish it properly on PyPI.