Did you consider either of these situations in your analysis?

Your dilemma should be easy to resolve — port your .NET app to some lesscode platform. I know that it’s an expensive proposition, but no matter how you slice it, lesscode always makes more sense than morecode.

I also don’t like the idea of adopting a comment format that isn’t accepted by the wider community but I’d like to have a bit more than plain text.

If you mean the default text format, that’s true. But epydoc does support restructuredtext, too. And AIUI, there’s no accepted standard way of documenting parameters, return values, etc.

To John: I have to respectfully disagree with your assertion that ActiveRecord is only suitable for simple data models. However, I equally agree that Og/Nitro is, in itself, also very interesting.

To John: I have to respectfully disagree with your assertion that ActiveRecord is suitable for simple data models. However, I equally agree that Og/Nitro is, in itself, also very interesting.

To Ryan: Yes, RDoc is included in the core Ruby distribution.

Well, we hate to see you go, Ryan. I know I’ve gotten a lot out of your contributions in the Python world.

Awww, shucks…

No, but seriously, I’m not really going anywhere. You can take Python from me when you pry it from my cold, dead hands :)

I’m going with Ruby/Rails as an intrinsic piece of a basic platform for web apps built by the company I’m currently involved with. But I’m not dissing on Python and I have no plans of abandoning it.

RDoc, to my eyes, does not look any better than epydoc

epydoc has the same issues as pydoc with regards to using runtime introspection. I also don’t like the idea of adopting a comment format that isn’t accepted by the wider community but I’d like to have a bit more than plain text. Lastly, I’ve found it overly complex to extend epydoc’s core theme and layout.

RDoc uses source scanning as opposed to runtime introspection and I personally feel this yields better results for HTML reference documentation. (As a side note, Pudge actually uses both. It scans the source to find out what’s where, in what order things are defined, and tries to pick up non-docstring comments.) RDoc is also accepted by the Ruby community as a standard and will be (or maybe already is) included with Ruby core. I don’t have to worry about my formatted comments being unparsable next year when a new doc tool is invented. Finally, RDoc has a basically good and complete customization mechanism which I’m currently using to get rid of the frames, among other things.

RDoc, epydoc and Javadoc are all fine tools, but I don’t think you’d generally want to create a whole website with them.

I’ve had good luck so far combining RDoc and reusable Rake tasks to
generate both source extracted documentation and website style content. It’s not quite what I had in kid/pudge/buildutils yet but its not far and I haven’t spent that much time on it.

I can certainly understand why you would choose the toolset you did. Back when I started Zesty News, I was strongly tempted by Rails. I chose Python instead, largely because I felt my choices for packaging a desktop-installed webapp were better.

I do have a couple of comments: RDoc, to my eyes, does not look any better than epydoc, both of which are based on Javadoc. RDoc, epydoc and Javadoc are all fine tools, but I don’t think you’d generally want to create a whole website with them

Personally, I haven’t missed Rake. The first thing I did when I started Zesty News was create an automated build script (not distutils-based). Between the os, shutil and the occasional other module, I was able to easily automate every aspect of my build, using standard, procedural Python. That said, I do agree that a tool like Rake can help newcomers (and new projects) get up to speed more quickly. The work being done in setuptools and what you’ve done with buildutils does solve some of the problem there.

Gems are terrific. For me, there’s a kernel of stuff going on in setuptools that is cooler than what Gems offer (from what I’ve read), but I have unusual requirements.

I think you already have an idea where I stand on web frameworks, and I hope to write more about that late this week or early next.

Thanks for sharing all of this with all of us. Having a spotlight aimed at cool stuff that’s happening elsewhere is always invigorating (to me, at least).