Playing with Bro packages and bundles, there's one thing where I ended up a bit confused and that's the meta data. We have two places right now that store meta data about a package: there's the central set stored with the package source (bro-pkg.index), and then there's the set coming with the package itself (bro-pkg.meta). However, I'm a bit lost what goes where, and which information should remain accessible once things are bundled up.
Seems bro-pkg.meta generally has "description" and "tags" at least. However, that information seems lost once I bundle a package up and don't have access to the index repository anymore. There doesn't seem to be an expectation that bro-pkg.meta would have similar information, so there's nothing there to fill the gap. Then, bro-pkg.meta has a "version" field (the docs show that as the one field to put in there). I believe that version isn't really used anywhere other than showing it as part of the meta data output in "info". In Python it also maps to PackageInfo.metadata_version. But then there's also PackageStatus.current_version, which is from git (although I'm not sure how I would actually set that; is it just any tag?). Once packages go through bundle/unbundle I cannot run "info" when I'm offline, and hence I don't get some of the information anymore (same from Python with PackageInfo I believe) Ideally, what I'd like to have is a single interface (speaking in Python API terms) for a package that gives me all the meta-data consistently, pulling it out from where's it's stored and maintaining it when bundling. For things like "description", "tags", it could pull them out of bro-pkg.index by default, and maybe override them from bro-pkg.meta if they are defined there (so that one can set them even if there's no package source to begin with). And bundles would then carry the information through, probably inside their manifest. For version information, bro-pkg could start with the git branch/tag but override it with values from bro-pkg.index and bro-pkg.meta if defined there. That way people could choose how to do their versioning. The API would just offer a single version() doing the right thing, and "bro-pkg info" would show that. Does this make sense? I'm not quite sure about the reasons for the current structure, I'm mostly thinking from the perspective of information about the package I'd like to have access to easily, and where it's coming from. Robin -- Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev