From a comp.lang.tcl posting by Larry Virden

1. Avoid simple, obvious names for your namespace - someone else probably is also using it. Search this Wiki and comp.lang.tcl [1] to check your name is not in use.

2. Avoid global variables, procedures, etc. - they are almost certain to clash with something someone else has done. Likewise, don't export package names that you do not intend as a public interface. This really messes up people attempting to make use of tcl's introspection capabilities.

3. Avoid hard coding pathnames, socket numbers, etc. - they are almost certain to clash with how someone else needs things configured. Trying to force someone else to do things your way is a great way to lose friends and influence enemies...

4. Make a variety of docs available - man pages for Wnix users, winhelp for Windows users (if your package can be used there), html for Mac and other platform users, etc.

5. Make it easy for users to report bugs - and let them know when the bug fixes are available...

6. Keep up with the latest releases of Tcl.

7. I know that for me, I appreciate it when packages use the same terminology in the same manner as Tcl when doing configuration. Moving things around, requiring binaries from the Tcl source directory, etc. is very annoying.

---

See Extending Tcl for general information about writing Tcl extensions.

---

For the person new to Tcl, one might wonder whether there is a difference between the use of the term package and the word extension. Generally, no. Tcl actually has a package command, but there is no extension command. So package is probably the better term to use.

---

LV writes, on comp.lang.tcl, the following comments about taking a script package from the wiki or other places and installing it:

Premise: a user sees a web page, usenet posting, etc. that has tcl code which implements a series of procs. How do they move from this finding into having the ability to package require it?

1. Let's pretend, for the purpose of this discussion, that our hypothetical package is called "fschanges".
2. Let's pretend that we would find this package at some location on the net - say the web page mentioned above.
3. The first thing that the user would need to do is to download the tcl code and save it as a text file. Let's say they save it as fschanges.tcl
4. Now, they edit the saved data to ensure that only lines recognized by Tcl are inside the text file.
5. Now, the next step is to create a sub-directory inside one of the tclsh's auto_path directories - or into a directory that will be added to the tclsh's auto_path. For the sake of this illustration, let's pretend we are using /usr/lib/tcl8.3 . So the user would create a subdirectory called /usr/lib/tcl8.3/fschanges-0.1/ . The version was included in the directory name so that as things in the extension change, you create a sibling directory called, perhaps, 'fschanges-0.2, to contain the next version. Some people build packages that just install into package name ... that may work for some. But it makes life difficult when code exists that depends on the previous behavior.
6. Into that directory, the user would copy the fschanges.tcl file.
7. Now, the next step would be to create a pkgIndex.tcl file. Unfortunately, this is the step that doesn't, to me, seem as well documented on the wiki. See pkgmkindex for a page that serves as a central clearing house for info about the process.

---