|Version 6 (modified by 3 years ago) (diff),|
Plugin Development Guide
This document captures some best practices and guidelines for plugin development. It is a community driven document, and everyone is encouraged to contribute to it. If you have questions or comments, please raise them on the Trac-dev MailingList.
Plugin authors are encouraged to clearly indicate how the contribution is licensed. This is important for both users and future !developers of your plugin. Having a clearly defined license allows someone else to adopt and carry on development of the plugin if you choose to no longer support it. It is also important for users and administrators who need to understand the terms and conditions under which they can use or modify the code.
Trac-Hacks is an open source community driven by voluntary contributions and made successful by collaboration. Therefore we encourage the use of licenses that foster collaboration and minimal restrictions on future use of the code. Trac has adopted the BSD 3-Clause license, and use of the same license in any plugin code is encouraged. One of the many benefits to adopting this license is that any plugin code can potentially be integrated into the Trac core down the road.
The following steps are suggested:
- Add the
- Add a license header to every Python source file (example).
# -*- coding: utf-8 -*- # # Copyright (C) your name here <your email here> # All rights reserved. # # This software is licensed as described in the file COPYING, which # you should have received as part of this distribution.
- Add a license header to every HTML template (example: TBD).
The use of the XML comment marker as shown is important so that the text does not get rendered to the output. Make sure not to use the alternate form, which is rendered to the output as a hidden comment:
<!--! Copyright (C) your name here <your email here> All rights reserved. This software is licensed as described in the file COPYING, which you should have received as part of this distribution. -->
<!-- This is also a comment -->
- Add a
COPYINGfile with the license text in the top-level directory of the project (example).
- Add an appropriate tag to the wiki page: bsd-license, apache-license, gpl-license, lgpl-license, mit-license. Additional tags can be created for additional or more descriptive license types
Currently it is not recommended to add license text to static resources (i.e. file in
htdocs), since doing so will increase the size of the content that is sent to the client. This issue will be addressed in the Trac core when support is added for minimization (trac:#10672).
Assert Minimum Trac Version Requirement
The most common method employed to specify a minimum required Trac version is to add an installation requirement in
setup.py. For example:
install_requires = ['Trac >= 0.12']. This causes numerous problems, some of which are documented in #9800, and is not recommended. One of the most negative consequences is that setuptools may download and install a newer version of Trac. The result can be an unintended upgrade of a user's installation (#10607).
A better approach is to place the following in the package
min_trac_version as appropriate for your plugin:
import pkg_resources min_trac_version = '0.12' pkg_resources.require('Trac >= %s' % min_trac_version)
The check if performed at runtime, so the egg can be built in an environment that does not satisfy the installation requirements. One use-case for this behavior is building the egg on a development computer and uploading it through the plugin admin page. An error such as the following will be seen in the logs if the plugin fails to load due to a failed requirement:
02:39:22 PM Trac[loader] DEBUG: Loading changelog.ChangeLogMacro from /home/user/Workspace/clm/lib/python2.7/site-packages/ChangeLogMacro-0.2-py2.7.egg 02:39:22 PM Trac[loader] ERROR: Skipping "changelog.ChangeLogMacro = changelog.ChangeLogMacro": (version conflict "VersionConflict: (Trac 0.12 (/home/user/Workspace/clm/trac-0.12), Requirement.parse('Trac>=1.0'))")