Edgewall Software

Opened 4 years ago

Closed 4 years ago

Last modified 14 months ago

#13120 closed enhancement (duplicate)

Towards independence from a SQL database based design

Reported by: nick@… Owned by:
Priority: normal Milestone:
Component: database backend Version: 1.3dev
Severity: normal Keywords:
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:


This is a design suggestion / question.

Have looked a lot for tool that allow me to combine knowledge from wiki and code.

Have been using Confluence for years and it is a great wiki but since removal of WikiText based syntax I find hard to think about this interlinking.

I believe Trac is unique due to its wiki centric design and has great support for both markdown and restructuredText.

Ideally it would be Git based - some wikis are - so that I can use regular files to edit knowledge, version control changes and process the pages with things like Laika.

I understand that Trac needs a database to provide for the ability to refactor/rename wiki pages while maintaining the interlinking.

My request is if it is somehow possible to export the wiki pages to external files (could be source controlled in Git) but/and still be able to "process" as if they were in the database.

For example I would like to generate a static website that looks just like the one served by the server but without the ability to edit.

Also, would like to use Laika to process these exported pages because of its great way to customize restructuredText (see http://planet42.github.io/Laika/extending-laika/extending-rst.html).

The gist of my ask, from a design standpoints, is for a way to abstract over the fact that pages are in the database and make it possible to work with them using the Trac core code, even if they are on disk.

Maybe there is no actual change required to core code and there is already a way to use the core Trac code/api somehow to generate such a static website and process externally?

Hope this is not too obscure. Please advise if and how I can clarify. Thanks Nick

Attachments (0)

Change History (3)

comment:1 by Christian Boos, 4 years ago

Thanks for sharing your thoughts. Some of these concerns are really almost as old as Trac itself (for example, TighterSubversionIntegration).

It should, however, be possible to achieve what you're suggesting using Trac as it is now with the help of some external scripts. For example, you could dump the wiki into the filesystem and version that (e.g. git add -A . style), either at regular intervals or after every change by using a plugin implementing the IWikiChangeListener interface. Conversely, you could use git post-receive hook to integrate the changes made in this "mirror" repository and load them into Trac. See TracAdmin for help on the wiki dump and wiki load commands.

But going forward, integrating something like that at the very core of Trac still has its appeal (cf. also DistributedTrac).

comment:2 by nick@…, 4 years ago

Hello Christian - thank you for details/history. An Happy New Year! :-)

Still going through and absorbing this. Glad to see the community already considered these points. Some questions in the process.

01 Is functionality described in TighterSubversionIntegration implemented already? Should I understand it works with Git as well (installation says Subversion is optional)? Please provide any details you can spare for how to use some of this offline editing.

02 While familiarizing with Python code I tend to use MonkeyType and mypy to add types for comprehension.

If I introduce types to the Trac code base for my education towards using it for such a tool, would you accept the changes as a GitHub repo PR?

Instagram open sourced this https://instagram-engineering.com/let-your-code-type-hint-itself-introducing-open-source-monkeytype-a855c7284881. Dropbox and Google use something similar as a practice to maintain production grade code.

in reply to:  2 comment:3 by Ryan J Ollos, 4 years ago

Resolution: duplicate
Status: newclosed

Replying to nick@…:

01 Is functionality described in TighterSubversionIntegration implemented already?

Not implemented, see #1132. I would focus on writing a plugin following the comment:1 suggestions.

02 While familiarizing with Python code I tend to use MonkeyType and mypy to add types for comprehension.

You could raise the issue on the trac-dev MailingList. I see value in adding type hints, particularly to aid plugin developers. I'm not sure we'll want to put effort towards that until we are transitioned to Python 3 (#12130), but maybe you can tell us whether there is any need to wait until Python 3. I recommend adding type hints for just a single module to start with, and that can be a basis for the mailing list discussion.

Closing as a duplicate of #1132. For further discussion of this topic the trac-dev MailingList is recommended.

Modify Ticket

Change Properties
Set your email in Preferences
as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none) to the specified user.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.