Problem: people want to know things about packages other than version and load script.
Solution store/retrieve name-value pairs
Alternative name?: [package meta]
No required names; let conventions arise
How do package variants share a single metadata?
When does metadata need to be available? Only after loading a package? Or earlier?
If earlier, [package about] calls need to go in index scripts, and automatic indexers should be able to place them there.
Does this complement or compete with TIP 59? If compete, who wins?
This would mesh well with the metadata provided by TIP 55 (see Cantcl) which could be available before loading packages. Since the format is name/value pairs it fits into the above scheme.
I'd suggest [package info ...] though and perhaps a more sophisticated query interface. Eg. [package info -subject web] might tell me the names of any packages with a subject field of web that are currently installed. [package info -repository $url -identifier ncgi] might give me info (a pair list?) about a package in a remote repository.
DGP Greater sophistication is fine, but I see that as additional functionality to be built on top of a very simple [package about] command. I imagine that first [package about] provides the primitives, then conventions arise for good conventional name/value pairs that should be used (inspired by TIPs 55 and 59 in part, I'm sure). Then when conventions are established, more sophisticated procedures that process [package about] information according the the evolved conventions. This separates policy from capability. I think that's a good thing.
AK I am with Don here. I.e. keep the base command simple and implement more complex functionality, like sophisticated searching capabilities on top of it.
SC Is there a need for setting metadata values?
DGP If we never set them, how can we query them? So.... Yes.
SC It depends on how you expect the values to get there. Your statement assumes that they are placed there by running code.
DGP Yes, I think of it being very similar to [package ifneeded].
SC TIP55 metadata is stored (on purpose) in a text file and IIRC TIP59's metadata is stored in the executable -- ie. is set at build time. Your comments above suggest that [package about ...] would be a general metadata mechanism which eg. a TIP55 metadata parser could use to, hence it would need set.
DGP I want [package about] to be useable by packages that have no compiled components; hence, no build time.
AK Regarding [package info] versus [package about] my stance is that info commands and methods are for introspection of the current state of the interpreter, runtime state that is. And as I consider the package meta-information not as runtime information, but something I can query even if the package is not loaded I like about better than info.
SC has no big argument...
Martin Lemburg - 15.10.2002:
What about using an enhanced info command instead of package about or package info?
DGP My opinion is that [info] is an overloaded mess already, and I definitely do not want to make it any worse. The [package] command is the right place to store information about packages.
Currently the info command collects many independent things like information about commands, procedures, variables, the runtime environment, ... - why not adding package information?
So what about using:
info package ?-(author|subject|keywords|(desc(ription)?)|version|licence|url)? packageName
Using info package should return a list of all available information!
Enhancing the info command could be done easily without modifying the core, just via initializing the interpreter (while sourcing init.tcl). So this could be done with the next patchlevel, after specifying the way of providing the needed package information!
The info command could be enhanced for info level, too: info level ?-(args|(proc(edure)?) level.
This could be a new way of detailing needed information inside the info command.