- Who wrote this?
- When was it released?
- Where was it downloaded?
- What variant is it? (or is this TIP 59? - AK yes)
- [package about $package $version] - return the metadata names stored for $version of $package
- [package about $package $version $name] - return the metadata value of $name for $version of $package
- [package about $package $version $name $value] - set the $value of $name for $version of $package
AK:
- Availability of metadata: IMHO should be useable even before loading. Enables package management tools for packages without having to load their functionality into the tools. Which can be difficult if the packages are variants and do not match the interpreter running the tool.
- [about] versus TIP 59: I believe it is compete, because TIP 59 specifies a way to implement meta data storage which is invalidated by [about]. It is a different system. Parts of TIP 59 are retainable, nameley the specified keys for Tcl.
What do people think about the ``set'' interface above? It sets only one value. Should it be extended to accept any number of name-value pairs? If so, doesn't that raise the {*} problem?
SCThis 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.SC This is where the TIP55 metadata format comes in, store the metadata in a text file inside the package directory and [package about] could find it. The advantage of a text file is that no sourcing of possibly suspect code is needed and you can find out about the package without loading it (as you can via pkgIndex.tcl of course). If I'm running a web based repository, I don't want to have to source Tcl code to find out about the packages that folks upload, even with safe interpreters it's much easier to use a simple text file format.
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?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)? packageNameUsing 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.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.In addition the specific suggestions above make the same attempt to define policy instead of just providing capabilities out of which policies can be constructed.AK: Thanks Don. Nothing to add from my side.SC picking up this policy/capability thing. You're suggesting I think that [package about] is a good core capability that should be added to the core so that future policies on package metadata can use it. I guess I've no argument with that except that I think we need to set up the policy on package metadata now and that how [package about] works might depend on the policy (just as how [package require] depends on the policy about where pkgIndex.tcl sits and what it contains.DGP You're making my point. One of the great strengths of [package require] is that it does not depend on things like where pkgIndex.tcl sits, etc. Really! All that stuff is just a default implementation of a very generic [package unknown] mechanism. Likewise, CANTCL would build on a specific policy constructed out of the very generic [package about].
