[Bro-Dev] package manager progress
vallentin at icir.org
Mon Jul 25 08:18:01 PDT 2016
> The package manager client is at a point now where I think it would be usable.
> * Add a way for package’s to define “discoverability metadata”.
> E.g. following the original plan for this would involve putting
> something like a “tags” field in each package’s pkg.meta file, but the
> problem with this is the client would need to either download every
> package to be able to search this data or have a third-party
> periodically aggregate it.
What does "downloading" a package mean? If the package is in the
.gitmodules of the repo bro/packages, won't it be automatically
downloaded once the user updates their submodules?
> I put it at lower priority since I don’t think it will be common right
> off the bat to have complex package dependencies and users can always
> manually resolve dependencies at the moment.
Agreed on inter-package dependencies. How about specifying a specific
Bro version as "dependency"?
> * Documentation is hosted on GitHub at the moment, move to bro.org?
A key benefit of hosting it at github is reliability and that clients
get good viewing performance thanks to their CDN.
> The current doc/www setup feels like it’s getting rather
> large/monolithic and maybe that contributes to the difficulty of
> approaching/understanding it when there’s breakages. Just an idea.
Keeping it separate could be an advantage for users, because the current
documentation is a bit unwieldy and confusing. Since you've written it
in RST, have you thought about publishing it via read-the-docs? Their
documentation really reads very smoothly out of the box. CAF, for
example, recently switched to it .
Some minor feedback:
- Is the "refresh" command essentially what "update" is to Homebrew? The
Update local package source clones to retrieve information about new
packages that are available. Also fetches updated package
information about any installed packages to determine if new
versions are available.
It sounds like this means it's doing submodule update.
- The documentation of the "list" command says:
Filters available/installed packages by a chosen category and then
outputs that filtered package list.
I don't understand what "available" means here. It could also mean
"packages that exist remotely but not installed locally" as opposed to
"available for use right now." To avoid ambiguity and clearly
distinguish it from "search", I would make that clear in the
- Regaring pkg.meta: this is more of a nit/style thing, but I like
minimalistic naming of configuration options, e.g.:
version = 1.0.0
scripts = /path/to/scripts
plugins = /path/to/plugins
I find them easier to remember. But Robin would probably disagree with
me here :-).
Looking forward to see it shaping up!
More information about the bro-dev