Packaged Trac
Jeff Hammel
Installing trac is pretty easy. I'm going to (*) steps I find useful but aren't strictly necessary.
[0. install system dependencies (databases, svn bindings, python etc.) I'm not going to touch these here]
* 1. create a virtualenv ( http://pypi.python.org/pypi/virtualenv )
2. install trac into the virtualenv
* 3. install poacheggs ( https://svn.openplans.org/svn/PoachEggs/ )
4. install plugins. For this i use poacheggs and a requirements file (this one, though this version is somewhat outdated: https://svn.openplans.org/svn/TracPlugins/plugins.txt )
5. do the configuration.
So the install process, minus the configuration, can be a 5ish-line shell script. Its not a great solution, and questionably a turn-key solution, even if you do something clever with configuration, but it gets things most of the way there.
Since this seems to be a big issue, as a recommend hosting "installs" on trac-hacks, which would be aimed towards turn-key-ish installation procedures. I'm imagining anything from the quick+dirty approach I show above ("this is the install our organization uses. It aims to provide a trac that....") to configurable and smart installers. I figure if there is as much interest as there seems to be, then sharing our various methodologies might eventually build to something (or some things, as the case may be) that are of general use to many people. If there is enough interest, maybe an "Install" section on trac-hacks might be a good idea.
Any thoughts or interest? Its not my top priority, as my install procedure worksforme, but if people think this is a good idea, I'm glad to codify my rudimentary install for reference.
Jeff Hammel
The Open Planning Project
http://topp.openplans.org
Pavel Kourochka
Is it possible to create an egg meta-package that includes Trac plus
some useful subset of plugins plus some configuration for them?
From my observations, newbies have problems when they 1) find good
plugins; 2) find proper versions of the plugins; 3) find how to
configure the plugins properly. As result, they say that Trac is hard
to install/extend/maintain.
Thus, it would be a good idea if there are packages like
Meta-Trac-0.11-OpenPlans-1.0.egg, which includes Trac, plugins, and
configuration tweaks.
It looks that this will not only allow others to install Trac with
plugins easily, but also it simplifies maintenance of existing Trac
installations - the whole package can be tested/updated by a single
command.
This is just an idea, but it looks that it minimizes the Trac plugins
hassle by reusing ready-to-go packages/configurations.
Regards,
Pavel
Robert C Corsaro
> There has been much discussion on this list and elsewhere concerning installing trac + plugins out of the box, and probably doing configuration. Several projects, such as oforge, already do this sort of thing, but there is a perceived need for either other methodologies or perhaps more of a community effort towards this solution. I'll going to share my methodology that I use for installs and suggest a short-term methodology for trac-hacks dealing with this issue. Nothing here is meant to obviate the need for longer-term methodologies, such as (just naming random ideas I heard) making plugins installable/browsable via the webadmin interface, setting up a PyPi for trac-hacks, better orphaning and adoption of plugins, and other ideas that can't (or at least won't) be done in a day.
>
We would like OForge to be a community driven project, and not just an
Optaros project. I'd like to make it clear that having outside
contributers is one of the main goals of a doing public release. We
don't want to fork anything, but to be active members of the community.
The work we put into each component of OForge should be usable by
projects outside of OForge's scope.
As far as one blessed trac distribution, I don't like the idea. As has
been mentioned many times, users have different needs. OForge, as it
currently stands, serves our needs. That of a consulting company with
many clients. We would expect that our users/contributers would have
similar needs. It could be that OForge fulfills the needs of other
types of users, that we haven't even considered. That would be great,
but we don't expect OForge to be the end all, be all of Trac
distributions. I think that there is room in our community for multiple
trac distributions that suit different needs.
Noah Kantrowitz
Really I don't think there is. Not in a bad way, but it seems like the
insane flexibility we have created can sometimes be overwhelming to people.
The idea of having the One True Turnkey Trac would be that it offers far
fewer choices, but gives a new team the kind of structure and guidance many
people seem to want. This also extends to things like the Trac install
process. Many people don't know which of the dozen deployment options to
choose so they decide "Trac is hard to install", when really getting Trac on
tracd running takes no more than ~10 commands. I think giving people some
kind of package that has all the best practices they have been hearing about
setup and ready to go will lower the barrier to entry for a lot of people.
And if they decide they want the flexibility back, Trac Classic will be
waiting on the sidelines for them.
--Noah
John Hampton
I agree with Robert here. Having one blessed "turn-key solution" for
trac only creates its own problems. Problems I see are:
1) We get tons more bugs on t.e.o regarding external plugins /
turn-key integration that should be someplace else.
2) Due to all the bugs and the fact that projectX is the blessed
version of trac, trac-core ends up taking over maintainership. This is
not a position that we want to be in
3) projectX ends up lagging behind core and or introducing some bugs,
the ire of which gets redirected back to core not projectX
I think that we should make it clear on t.e.o that there are projects
that bundle trac with some of the most popular plugins out there. I
think we should list said projects with the plugins/features they
provide. I think we should keep that list to absolutely no more than
five, and probably closer to three. This way we have "turn-key"
solutions that are available, and sanctioned by trac-core, but clearly
delineated from trac-core. If we retain control of the wiki page
listing said projects, we can keep the list small, and we can verify
that the projects are actually decent. We can also make sure that they
have a ticketing system and can then refer all tickets that end up on
t.e.o to the proper project.
I think that if we make only one "blessed" project, then we may as well
just make it trac.
-John