Uma G. wrote:
So I’m trying to use Trac for our FUN3D development,
as an experiment for a potential NASA-wide installation,
but Trac is not the easiest thing to get setup. Lately,
I’ve even had to hack some of the Python internals to
get syntax highlighting working via enscript.
For the Python-clueless in me, it wasn’t easy to set-up Trac.
But after the initial pain things went rather smoothly.
I recently installed Trac on CentOS 4.something; never saw a lie of
Python. Used yum. (Figuring out how to use yum for this was a tad
annoying … )
I agree the ideal situation would be one were we could hack and add
qualities to the tool (I’m always finding names for things, Rutrac,
Tracby ?) but it seems so far, the quality of Trac has largely
outweighed the pain of being subject to Python.
Done much Python? Where’s the pain?
Really, unless you’re writing an app, hacking Python here and there is
not far from hacking Ruby. (Assuming your editor is correctly
configured for the static indentation.)
Is it the main reason for a port would be to eliminate the pain of
hacking in Python, or is it something else we would be able to do with
Ruby that is (near) impossible with Python ?
A lady will always prefer gems to snakes, of course, but I’m trying to
find out whether there are powerful reasons to port Trac so that the
Ruby community would be willing to throw its weight behind.
I’ve acquired a fondness for DokuWiki, WordPress and TextPattern.
That’s right: P fuckin’ HP apps.
Why? Because I rarely need to actually look at code. And when I do,
it’s trivial to do what I need. But, fortunately, that’s not very
Sometimes (well, often) I roll my own apps because I want to hack on
something while exploring, because I’m not exactly sure what I want it
to do, and I want to get it Just Right for James. That’s why I wrote my
own blogging software. That’s why I wrote my own application deployment
suite. That’s why I wrote my own publishing tool.
But other times I just want the app to get out of the way. It’s nice
when something is written in Ruby, but if looking at its source code is
not what I really want to be doing, then it’s a moot point.
My blogging software is great for me, but not my niece; WordPress means
she can do great stuff without learning Ruby. It’s a Web appliance.
Same goes for Trac. I’ve made some tweaks using OPC (other people’s
code); snake-handling is kept to a minimum, and Trac simply lets me
focus on what I want to do: manage my own Ruby projects.
Otherwise, solo efforts may not be the best idea for this kind effort
with little or no noticeable reward.
(in the end you will just have something that looks and smells like
Trac, only with Ruby inside)
Then more people will be hacking on Trac and fixing its bugs and writing
plug-ins than they will for RuTrac (or whatever), simply because Trac
has the critical mass for that feature set.
I know people writing project management tools in Ruby, but they’re
doing it because they don’t want Trac; they’re scratching an itch.
That said, I have been writing Ruby tools that treat WordPress, Trac
etc. as black boxes of behavior. (Maybe one day I’ll get around to
releasing my Tracula project. )
I don’t usually like re-inventing too many wheels, but pimping out the
ride is OK.
http://www.ruby-doc.org - Ruby Help & Documentation
http://beginningruby.com - Beginning Ruby: The Online Book
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys