Towards independence from a SQL database based design

[nick@…]

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

[Christian Boos]

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).

[nick@…]

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.

• ​http://mypy-lang.blogspot.com/2017/11/dropbox-releases-pyannotate-auto.html
• ​https://github.com/google/pytype

[Ryan J Ollos]

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.