PasteBin as tool development example

[karsten]

The tool is looking great! We are looking forward to using this on our install.

I remember from last November's PyATL Code Jam (right around the first commits for this project!) that the pastebin example was going to be written up as a series of posts on how to build tools for Allura... are those still going to happen?

From roadmap point of view, will this tool eventually grow into a gist-like functionality... right now, a Paste isn't even versioned. It may be interesting to see the evolution of PasteBin from the simplest-possible tool into versioning and beyond.

Also, some questions on design choices:

• there is a controllers directory, but there is nothing in there, favoring all controllers in app.py. While I know this is a stylistic choice more than anything else, and probably appropriate in this case, is there a heuristic here that would help tool developers make that decision? Number of controllers/exposed methods?
• the locations for tool icons and css directives to use them are, like the core bundled tools, stored in the theme provider's assets... so when this is made available to projects, it would show nothing (or the broken image). is this situation ever going to get better? For our custom apps, we have hacked this by setting our icons "../../%s" % g.app_static('images/icon.png') and then doing some inline css inserts. It works well enough, but while I agree that themes should be the source of first resort for icons, a tool should be able to provide a default.
• in setup.py, you are using exec open('forgepastebin/version.py') vs the import __version__ seen on most other apps. Are one of these The Allura Way?

[Tim Van Steenburgh]

Hey karsten, thanks for the feedback.

• Yes, we're still intending to do the blog posts, when we have time. :)
• Hadn't thought about versioning. Probably won't be a high priority, but it's an interesting idea. Feel free to contribute code!

Design choices:

• In general I'd probably always make a controllers directory. I like the clean separation, and it keeps things neat if your app grows and you end up with a bunch of controllers. In the pastebin I wanted to keep things as simple as possible, with an eye toward making this into a tutorial on building Allura plugins.
• Yes, this is a problem. I believe we recently created a ticket in Allura to rectify this so that tools can easily provide their own static assets.
• Either way is fine, but now that you mention it, the latter method does seem to be the way other Allura apps do it.

[Dave Brondsema]

I think using a VersionedArtifact would be good, if only for demonstration purposes.

I've seen (and used) exec open instead of import because the latter will automatically import init.py which may lead to a cascade of imports. Sometimes that causes a problem, depending on the current environment (what packages are installed already, etc), so exec open is a more reliable way to make sure setup.py commands will always run successfully.

[karsten]

Thanks for the quick response guys. It's encouraging to see tools external to /p/allura (even if as developed by geek.net folk!) being deployed out on SF, as I think that will start teasing out some of the complications that will help mature the platform aspects of Allura.

general

• cool. I am getting interest around that topic, and haven't been able to send anybody to anything other than the base docs and the code itself... PasteBin is already a much better starting point than the other tools (wiki, etc) for understanding the basics, so thanks! The stage that its in right now (where it's good enough to run on SF!) would be a great Miller time moment at the end of a first tutorial, with subsequent feature expansions like versioning being interesting extensions.
• I'll see how our internal users want to use it before committing to the "patches accepted" gauntlet. Like I said, I think the functionality of the tool is almost secondary to its teaching value, but if it gets traction, we might have some mods.

design

• So maybe this points to two workflows for new apps: the "right" pattern and the "light" pattern... to that end, would it be desirable to have:
  • the full process (as started in PasteBin) and a mechanism for achieving the stubbed-out boilerplate (e.g. AlluraSkel)
  • something, say EasyApplication, in-framework that helped build "really simple apps". I could see this as being attractive, maybe for wrapping external data sources/tools, building arbitrary forms, etc. Magic naming, DSLs, all that business
• Good to know that something is coming
• Good to know about the import vs exec thing.