> The package manager client is at a point now where I think it would be > usable.
Cool! > * 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 [1]. Some minor feedback: - Is the "refresh" command essentially what "update" is to Homebrew? The documentation says: 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 documention. - Regaring pkg.meta: this is more of a nit/style thing, but I like minimalistic naming of configuration options, e.g.: [package] 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! Matthias [1] http://actor-framework.readthedocs.io/en/latest/ _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev