I think having the ticket import be separate is a know solution to this existing problem. I think for something as specific as a Trac Ticket import, I like it being a separate tool outside of Allura core. Not only does it address the licensing but it follows existing conventions. I think we should continue setting the standard that things like custom importers, that only a select group will need, should not part of the core Allura distribution.
Also I feel that having these tools be outside of the core distro makes the idea of contributing a tool for Allura more attractive and approachable. I feel that the more examples of tools we have the easier it will for contributors to make their own. -- Wayne Witzel III (@wwitzel3) wa...@pieceofpy.com http://pieceofpy.com On Wednesday, November 20, 2013 at 10:58 , Cory Johns wrote: > The recent build failure has highlighted an issue with the Trac ticket > importer. Namely, it relies on code in > Allura/allura/scripts/trac_export.py which uses html2text, which is a GPL > module and thus not a required library for Allura. However, even though > the Trac ticket importer is optional and can be disabled, I believe it is > enabled and exposed to the user by default. > > We've dealt with this in the other importers by moving the importers that > depend on html2text to a separate, externally packaged library, e.g., > TracWikiImporter (http://sf.net/p/tracwikiimporter/) and > GoogleCodeWikiImporter (http://sf.net/p/googlecodewikiimporter/). > > Personally, I'm not really a fan of having the importers packaged > separately, since we had the discussion that it's better to keep tools in > the core distribution if possible to help them stay maintained, but if > that's the only option from a licensing standpoint, then there's nothing we > can do. However, since we have the ability to selectively disable > importers, I wonder if we've considered the option of having the importers > live in the core distribution, but disable themselves by default if their > requirements aren't met? Otherwise, we need to refactor the Trac ticket > importer code out to a separate package. Either way, something will have > to be done before our next release.
