649538 - Need a system where people can upload tools and keep track of them

Status: RESOLVED FIXED

(Testing :: General, defect)

Description

[cmtalbert]

This system is suspiciously like the Toolbox system that jhammel is working on.  In fact, this is his tracking bug.

Jhammel please update with current status and plans.

Comment 1

[Jeff Hammel]

So a pre-alpha is deployed at http://k0s.org:8080/ NOTE: While I will attempt to preserve data here entered on this instance, and I encourage usage and feedback, it *IS* a pre-alpha and was not originally intended for an audience.  The code lives at https://github.com/k0s/toolbox (to be moved to presumedly mozautomation/toolbox) and there is a semi-useless about at http://k0s.org:8080/about which corresponds exactly to https://github.com/k0s/toolbox/blob/master/README.txt which somewhat documents the software and lists several TODO items. (In fact, this documentation should be broken up to a user-facing about page, a TODO, and possibly something along the line of the incomplete https://github.com/k0s/toolbox/blob/master/story-of-toolbox.txt.)

I won't repeat everything but will focus on things pertinent to today's status. Toolbox is an index, not a hosting service.  Its purpose is to index and classify software and point to where it lives and make it easy to find.  Its secondary but related purpose is to point to what software can or should be combined.  The classifiers are specifiable via data state or configuration (currently internally:     
    usage
    dependencies
    type
    language
    author)
These are lists (in python terms) of strings.  More arbitrary fields are planned but probably unnecessary for round one. The HTML/JS interface is highly AJAXified.  There is no save/submit buttons for POST requests except for new tools and deleting tools. There is no auth though a POST-guard could easily be added (e.g. via WSGI middleware). The point of toolbox is to make it easy for anyone to curate data.

For an initial rollout, there are only a few things that probably need to be done. The name and URL of tools should be editable (pretty easy). How to use it should be better presented and the documentation otherwise cleaned up (easy but annoying).  The only big thing is, by request, change of the model.  Currently flat files are used, one JSON-blob per tool. Per request, this should be moved to e.g. couch.  A partial couch backend already exists.  The rest should be fairly easy to implement, but IMHO tests (probably selenium) should be written to ensure that functionality is not broken and to protect against future breakages.  Not a huge chunk of time, but not insubstantive either.  Migrations should also be written for the legacy sample data: https://github.com/k0s/toolbox/tree/master/sample

Deployment is pretty flexible.  k0s.org:8080 runs off of just paster serving the WSGI app and static files. This is probably fine for a production system though other configurations are possible.

Comment 2

[Jeff Hammel]

A few other nice-to-haves for the create project view (/new):
- this screen should be AJAXy wrt validation -- the submit button should only be for final tool submission
- should check to ensure there are no namespace collisions (e.g. you shouldn't be able to call a tool "about" as this conflicts with /about)

Comment 3

[Jeff Hammel]

Done: http://brasstacks.mozilla.com/toolbox/