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.
I recently read that the Rails-based alternative, Collaboa
(http://collaboa.org/) is on the move again, but I can’t
even see code.
What’s up?
Thanks,
Bil K. 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.I recently read that the Rails-based alternative, Collaboa
(http://collaboa.org/) is on the move again, but I can’t
even see code.What’s up?
Thanks,
What system were you installing this on? I’ve always found Trac very
easy to setup and stable to use.
Oh yeah…
I’d love to see something like Trac in Ruby too 
But I guess it will still take some time, dont even
know if porting Trac-python into Ruby would be as
easy ;(
On Dec 21, 2006, at 12:55 PM, Bil K. 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.
You are definitely right that it’s a pain. Everyone pretty much
tolerates it though, because it is definitely the best of the best.
I recently read that the Rails-based alternative, Collaboa
(http://collaboa.org/) is on the move again, but I can’t
even see code.
I’ve seen many want-to-be-Trac programs. None of them go the
distance, sadly. When I last looked at Collaboa it didn’t have or
even plan to include a wiki. That kills it as a Trac replacement for
me.
And really, is Rails deployment much better than Trac deployment? 
James Edward G. II
On 12/21/06, Marc H. [email protected] wrote:
[snip]
I’d love to see something like Trac in Ruby too
[snip]
+1
installing bugzilla wasn’t easy.
installing trac was relative easy to install.
besides that trac is very good. but a rubytrac would be even better.
I have an experimental version of collaboa I’ve been hacking on this
week that adds a wiki and timeline support.
I plan on giving the patch to add both of these back to the collaboa
and if they don’t want it, I’ll maintain it seperately. I adore the
wiki integration with the ticket and SCM system. But I didn’t want to
have to hack python when I wanted to change something. Collaboa is
pretty simple and adding the wiki and timeline have been pretty simple
so far.
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 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.
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.
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)
Uma G.
Michael G. wrote:
What’s up?
Thanks,
What system were you installing this on? I’ve always found Trac very
easy to setup and stable to use.
Same here. Well, after all the fsck’n Python dependencies are in place.
But I’ve had more issues installing svn than Trac.
I’ve started assembling some Ruby helper scripts for certain tasks
(creating a new Trac project; modifying user permissions) but still find
Trac best-of-breed.
But it’s been a while since I’ve looked at Collaboa (which, at the time,
was a poor runner-up to Trac).
(Trac + darcs would be sweet, but as far as I can tell it is only really
doable through an svn-sync hack.)
–
James B.
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
Bil K. wrote:
What’s up?
I think there is a tendency to overestimate tools like Trac. I did so
myself for a long time until I released that just by organizing my
project’s folder in special way it could used as a project web app in
itself. It’s nice just to mix and match stand-alone components for the
purpose.
T.
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
often.
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.
–
James B.
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
Ernad Husremović wrote:
It led me to the http://www.retrospectiva.org
I have tried retrospectiva and It seems me quite usable and features
rich.
Many thanks! Retrospectiva is currently under heavy development. I hope
to able to release 1.0RC1 soon, but I need some more help with testing
(stability is a key goal of Retrospectiva). Please check the website for
announcements and further infos.
Dimitrij
Bil K. wrote:
I recently read that the Rails-based alternative, Collaboa
(http://collaboa.org/) is on the move again, but I can’t
even see code.
Searching collaboa-talk mailing list, I have found conversation about an
collaboa fork:
http://lists.collaboa.org/pipermail/collaboa-talk/2006-December/000463.html
It led me to the http://www.retrospectiva.org
I have tried retrospectiva and It seems me quite usable and features
rich.
Regards,
Ernad
Ernad Husremovi wrote:
It led me to the http://www.retrospectiva.org
I have tried retrospectiva and It seems me quite usable and features
rich.Many thanks! Retrospectiva is currently under heavy development. I
hope
to able to release 1.0RC1 soon, but I need some more help with testing
(stability is a key goal of Retrospectiva). Please check the
website for
announcements and further infos.Dimitrij
Thanks for the link Ernad! It does look quite good
Dimitrij, I looked at both the about pages for Retrospectiva and
Collaboa, but I couldn’t get a clear sense of why you decided to
start a new project, rather than work on Collaboa. I get the
impression that it has something to do with the extensible
architecture in Retrospectiva. Is that correct? If you’re willing,
I’d love to hear some of your justifications.-Mat
I wrote a note about my reasons on the collaboa mailing list
(http://lists.collaboa.org/pipermail/collaboa-talk/2006-December/000465.html).
You’ll maybe also find some answers on the Retrospectiva mailing list:
http://rubyforge.org/mail/?group_id=2685.
Cheers,
Dimitrij
On Jan 4, 2007, at 9:13 AM, [ Dim — wrote:
website for
announcements and further infos.Dimitrij
Thanks for the link Ernad! It does look quite good
Dimitrij, I looked at both the about pages for Retrospectiva and
Collaboa, but I couldn’t get a clear sense of why you decided to
start a new project, rather than work on Collaboa. I get the
impression that it has something to do with the extensible
architecture in Retrospectiva. Is that correct? If you’re willing,
I’d love to hear some of your justifications.
-Mat
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs