Version 7 of package BoF: PACKAGE ABOUT - metadata

Updated 2002-10-12 16:19:52

Problem: people want to know things about packages other than version and load script.

  • Who wrote this?
  • When was it released?
  • Where was it downloaded?
  • What variant is it? (or is this TIP 59? - AK yes)

Solution store/retrieve name-value pairs

  • [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

Alternative name?: [package meta]

No required names; let conventions arise

Discussion:

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?

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.

SC

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.

Is there a need for setting metadata values?

DGP If we never set them, how can we query them? So.... Yes.