The '''Tcl Package Developer Guide''', part of the [Tcl Developer
Guide%|%guide%|%], provides information on developing [package%|%packages] for
[Tcl].



** See Also **

   [Packaging Extensions]:   information specific to the packaging of [extension%|%extensions]

   [How to build good packages]:   

   [TEA%|%TEA 2 documentation]:   "The Tcl Extension Architecture", Brent Welch, Michael Thomas, 1999



** See Also **

   [Tcl Package User Guide]:   

   [Tea]:      



** Description **

Arbitrary combinations of [extension%|%extensions%|%] and [script%|%scripts%|%]
may be combined into [package%|%packages], for easy deployment and use.


[JCW] was once heard to conclude, `Package require` ''is a contract to make a
certain API available, not a procedural-call-with-side-effects in disguise -
IMNSHO.''


   [http://www.tcl.tk/man/tcl8.5/tutorial/Tcl31.html%|%Building reusable libraries - packages and namespaces, Official Tcl Tutorial%|%]:   

   [http://www.wjduquette.com/tcl/namespaces.html%|%On Namespaces and Packages%|%]:   by [William Duquette].  Highly recommended reading. 

   [How to build good packages]:   general best practicies

   [A simple package example]:   by [RS%|%Richard Suchenwirth%|%]

   [http://math.nist.gov/~DPorter/tcltk/oscon/%|%Don Porter's Presentation at the 8th Tcl/Tk Conference%|%]:   A presentation by [Don Porter] about how package unknown works

   [http://www.larochelle-innovation.com/tcltk/207%|%Programmation modulaire en Tcl/Tk%|%]:   

   [Packaging of the Tcl world]:   ideas about further development of a standard package system for Tcl

   [into what directory should one install the various pieces of a tcl application or extension]:   



** Tools **

   [http://math.nist.gov/~DPorter/tcltk/package/%|%package%|%]:   a drop-in replacement for the built-in [package] command, by [Don Porter]



** Runtime Metadata ** 

[Don Porter] offers

======
namespace eval ::myIcons {
    # ...
    variable home [file join [pwd] [file dirname [info script]]]
    # ...
}

# ...

proc ::myIcons::getPath {} {
    variable home
    return $home
}
======

[DGP]: Hmmmm... since someone bothered to record that advice for Wiki
posterity, I should add that this is nothing more than an updated version of
the advice found in library(n) and tclvars(n) that each package should define a
global variable ''${package}_library'' analogous to ''tcl_library'' and
''tk_library'' storing the directory in which that package is installed.

That original advice came before [namespace], back in the bad old days when the
only persistent variables that could be defined were global variables.
(````Persistent'' in the sense that they live longer than the execution of one
[proc].)  Nowadays, we clearly shouldn't be defining global variables when a
namespace variable will do.

Also, I've moved away from a variable named ''library'' because I find that
word is used to just mean way too many different things.  It's just too
confusing.

[MGS] 2004-02-10: In my packages I create a namespace array variable
called ''pkginfo'' which contains values for ''package'', ''version'',
''script'', ''directory'', ''name'', ''description'', ''author'', ''email'',
''date'', ''copyright'', etc. Perhaps a '''package source''' command could be
useful here (to return the directory in which the requested package's
[pkgIndex.tcl] file is/was found) ?

[LV] 2007-11-16: it would seem to me that having some code (in my opinion as
part of the core) to which best practices could refer would be ideal. Then it
becomes a matter of going from package to package, suggesting that maintainers
add a line to their package to register the appropriate information.



** Interdependencies **

Don writes, "The main weakness is that the [[package]] system does not keep
track of what the interdependencies are. We get "can't find package foo"
instead of 'could not load package foo 1.3 because it depends on bar 2.1, and
that is not installed'." CL agrees with this, and complains that package
authorship is clumsy and error-prone.  Perhaps more on this subject will appear
in October 2001.


** Starkits **

[LV] 2007-08-30: 

Is it possible at this time to distribute a Tcl package as a single [starkit],
and have that single file be recognized by a developer/user's code?
If so, what steps would the package developer need to follow, and what
steps would the receiver of the starkit have to follow, for this to work?

<<categories>> Documentation | Deployment