We want this to be a community-driven library, so we encourage submissions to this library. If you have written a function or set of functions that you find you use frequently, send the code in! Ultimately, we want community members to be responsible for modules in tcllib, having CVS write access directly to specific modules in the tree. Please do not feel that you must have a "complete" module in order to contribute -- individual functions are welcome as well.Also, if you are using tcl code that was written by someone else, please contact that developer to help them contribute it to the library. The library should only include members' code with their cooperation, agreement, and support.
Important pages for Tcllib are
- http://tcllib.sourceforge.net/ -- Mailing Lists, some web presence
- https://core.tcl.tk/tcllib/reportlist -- Bug Tracker, aka Ticketing system
- https://core.tcl.tk/tcllib -- Fossil Source Repository
- http://www.tcl.tk/software/tcllib/ -- General landing page
In order to encourage growth and use of tcllib, there are some ground rules that modules added to tcllib must follow:
- the module must be Tcl only: no C extensions. This minimizes the barrier to use -- not everybody has the means or desire to compile extensions. We may someday start another meta-package of C extensions.
- The module must use a namespace for its commands and variables
- The module must be a proper Tcl package
- The name of the package must be the same as the name of the namespace
- The module must be released under the BSD license. If you cannot accept the terms of that license, please feel free to release your package independently of the tcllib. We feel that this license (the same one that Tcl itself is under) is the most conducive to use.
- The module should have both documentation (in XML or man form) and a test suite. The module _must_ have either documentation or a test suite, and preferably both.
- The module should adhere to the Tcl coding standards. See http://www.purl.org/tcl/home/doc/
- The module should be of general use to a large number of programmers. We don't want tcllib to become the dumping ground for every tcl programmer's personal, highly-specialized functions.
LEG 2009-03-16: feels that he would rather like to use the "simplified BSD License" variant, found e.g. at , and credit himself as OWNER for a contributed package, rather than the "Regents of the University of California".AK: Can you bring this up on the tcllib-devel mailing list ?
A follow up article by Jeff Hobbes said:Several have asked some basic questions of tcllib, which I will address here.
- Who maintains the module names?
- How can software be submitted?
- What software can be submitted?
- What is the release schedule?
# Major version bump: reserved for when new toplevel packages are added # Minor version bump: reserved for when new subpackages are added or significant functionality (like changed API) is made to existing packages # Patch version bump: bug fixes to existing packagesWe could go to a S.M.m.p system, where the new significant digit "S" refers to Structure, to allow ourselves versions in which we restructure tcllib.
- Will it become part of the core?
From Andreas Kupries, this msg was provided:1) What are the rules, requirements, restrictions for adding code to the tcllib?See (5) below. Also note that a patch of an existing module or a new module should contain not only the code, but extend the testsuite and documentation (manpages) too. Both of the latter will make acceptance easier as they allow to check the correctness of the code now and in the future.2) Who decides what does, or does not, get included into tcllib?Essentially the people who are registered as developers for the Tcllib SF project.3) Does anything get added into the library that someone submits?Yes. Recent changes were the acceptance of a patch [x] fixing a bug in pop3 and several new modules ("md5" [*], "csv", "matrix" (as part of "struct"), "report", "log" and "htmlparse").[x] Well, the patch was accepted a long time but Scott had troubles with committing it. When he tried yesterday it worked and so this bug finally squashed too.[*] Based upon Don Libes implementation of MD5, "md5pure", with changes by me (Trf soft dependency).4) Can Tk-specific commands be added to the tcllib?Modules that depend on Tk are placed in a sub project of tcllib: tklib5) Can Expect/Tix/Snack/etc. specific commands, which depend on some outside extension but which themselves are only script based, be added?The main rule/restriction which was set up at the beginning was that 'tcllib' is a script-only library which should work without any C-level extension. So the answer to the above is 'no'.This however does not exclude the usage of extensions to make tcllib faster, if it does work without the extensions too, albeit slower.Examples of this are the "mime" and "md5" modules. Both have a soft-dependency on the C-level extension "Trf". If "Trf" is present, "mime" and "md5" will use it in their implementations to make certain operations faster (base64 and md5 respectively). If it is not present, both modules will fallback to pure-tcl implementations.
In general I (AK) would advise the following:
- Go through your set of utilities and see if they match one of the existing modules of tcllib. If yes, submit a patch containing the new code and extended testsuite, documentation.
- If there is no match, create a new module in the style of the existing modules (see, for example, md5). Submit either a patch or an archive containing the new files.
tclguy has written, "From http://tcllib.sf.net/ go to the patch manager and post your code. You might want to examine the tcllib distro first, to see if it already fits well into an existing module, or whether one should be created for it."
Recently someone on the Tcllib mailing list (sponsered at SourceForge) asked What would one have to do to be added as a developer to Tcllib?. The answer by AK was One of the project administrators (like me) needs the name of your sourceforge user account to be able to add you to the list of developers for the project.Other things mentioned in the recent thread were:
- extending test cases when one fixes a bug
- creating test suites if none exist
- dropping a note to the tcllib-developers mailing list if any major features or changes are planned for a module, letting people know and making certain the direction being taken makes sense,
- writing doctools documentation if none exists
- follow the Tcl style Guide when writing or modifying code
- don't add new features without adding new doc
- bump revision numbers when changing files
- on questions of design, or naming, ask the developers mailing list
- be certain to specify the required level of Tcl using package require
TODO for this page ...
- ... list of suggestions for inclusion in tcllib? - separate page ...
- ... developer information ... internal structure, helper tools ... - maybe referenced from the rules ?
- ... other types of help ... (wiki helper, doc writer, tester, ...)