> On Jul 25, 2016, at 10:18 AM, Matthias Vallentin <vallen...@icir.org> wrote: > >> * 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?
Right now, packages don’t get downloaded via the submodule, they are cloned directly from the package’s full git URL (which git just happens to encoded within the submodule). So this means only packages a user is interested in end up getting downloaded. I think it also helps in cases where a user installs a package and later it gets removed from the package source — so the submodule is gone, but user’s installed version is not effected because it’s cloned directly from the package’s git URL. i.e. the package manager doesn’t distinguish between packages installed from a package source and packages installed directly from git URL. If we wanted, we could actually use something completely different from git submodules to register a package to a package source. The package source just has to have some sort of database that links nodes in a package hierarchy (e.g. alice/foo, bob/bar, eve/baz) to their actual URLs. Git submodules just happens to perform this role. Maybe another added benefit of submodules is that if someone (e.g. a web frontend) does want to download the “universe of packages” (maybe to do some global stats/analysis on it) its easy to do that with a single builtin git command. > Agreed on inter-package dependencies. How about specifying a specific > Bro version as "dependency”? Yep, that’s on also on the TODO list. > have you thought about publishing it via read-the-docs? Yeah, just haven’t looked into it. I’ll do that unless consensus is to host the docs on bro.org. > 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. I’ll try to clarify it in the docs. It doesn’t do a recursive submodule update, it just updates the source repo itself (so submodule additions/removals are visible, but nothing further is actually downloaded). > - 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.” It means the former — “list” operates on the combined set of installed and not-yet-installed packages. Does wording it like “Filters known packages...” make it clearer for you? > - 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 Open to changing it, but seeing “scripts” as an option, without reading any further documentation, implies to me that you might be able to specify a list of paths/files there, which you can’t. - Jon _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
