Updated 2012-10-11 21:56:26 by dkf ▲

If Tcl had a CPAN-like repository system, what would a package file look like? What data would you need to describe the contents of a package for download? I came up with this basic idea based on combinations of other standards already available. What else does it need? I realize that others have already gone at this, but I don't think there has ever been any kind of group consensus as to what this thing should really include. How much data is too much? Remember: KISS (Keep it Simple, Stupid).
 Package:   sample
 Name:      Sample Extension
 Summary:   A sample package that does nothing really.
 Version:   1.0
 Author:    Damon Courtney
 Packager:  Damon Courtney
 Copyright: GPL

 Created: 10/10/2001
 Updated: 10/20/2002

 Categories:

 Sources:
 http://www.sample.org/sample.zip

 Provides:
 sample-1.0
 sample::parser-1.0

 Requires:
 tclxml-1.0
 tdom-1.0

 Exports:
 sample::init
 sample::doit
 sample::main

 Platforms:
 Windows-x86
 Linux-x86
 source
 tcl

 Description:
 .This is a description.
 .
 .Some more stuff here.
 .
 .Ending line.

 Files:
 LICENSE         SIZE    CHECKSUM
 sample.tcl      SIZE    CHECKSUM
 sample.txt      SIZE    CHECKSUM

Most of these are pretty obvious, but I'll explain a few anyway.

Provides: Specifies the Tcl packages provided by this package.

Requires: Specifies the Tcl packages that this package depends on.
 Package names are defined as suggested by TIP #189: Tcl Modules.

Exports: A list of Tcl-level commands that are provided by the packages.

Platforms: A list of binary platforms as well as "source" if the source code to compile is also included, and "tcl" if the package has Tcl-only source. A tcl-only package would only specify "tcl" as its available platforms.

I open the floor up for discussion.

escargo 16 Mar 2006 - The field you labeled "Copyright" seems to actually be holding licensing information. The notions of copyright (effectively ownership) and licensing (the grant of permission to use) are related but still separate notions.

SC 17 March: See also Package MetaData Fields which asks the same question. Yes, others have done this before, and the main reason no progress has been made is that each time someone asks this question they ignore what's gone on in the past. Cantcl defines a file format for metadata like this, it also provides working code to handle the files and do some of the work of installing packages. Take it, build on it, why waste your time re-inventing it?

escargo - But are people ignoring what's gone on in the past because of failure to reach "any kind of group consensus"? Is there a consensus? If so, what is it? (For certain kinds of questions, there may never be a group consensus about what the right answers should be. Is this one of them? However, just as there are multiple popular editors, packaging systems, and languages, the trick would seem to be getting beyond the lack of consensus to the first working repository.)

See also:

Category DeploymentCategory DiscussionCategory Repository