Re: [Bro-Dev] package manager progress

> On Aug 5, 2016, at 6:37 PM, Siwek, Jon wrote: > > >> On Aug 5, 2016, at 1:29 PM, Slagell, Adam J wrote: >> >> If we are going to rely on metadata, which I agree can be better as you can >> tag a package with multiple categories, we should

Re: [Bro-Dev] package manager progress

> On Aug 5, 2016, at 1:29 PM, Slagell, Adam J wrote: > > If we are going to rely on metadata, which I agree can be better as you can > tag a package with multiple categories, we should probably have some basic > requirements for this type of metadata. At a minimum,

Re: [Bro-Dev] package manager progress

> On Aug 5, 2016, at 12:52 PM, Robin Sommer wrote: > >> >> Hhhm, is it naming conventions that people have a problem with or the >> implication of policing? > > The problem is that the suggested naming convention wouldn't work: > it's not clear how somebody would name their

Re: [Bro-Dev] package manager progress

On Fri, Aug 05, 2016 at 02:47 +, you wrote: > Hhhm, is it naming conventions that people have a problem with or the > implication of policing? The problem is that the suggested naming convention wouldn't work: it's not clear how somebody would name their plugin if it provided more than

Re: [Bro-Dev] package manager progress

Hhhm, is it naming conventions that people have a problem with or the implication of policing? These can be separated. I don’t see a downside to promoting conventions. It also seems that some of the reason (e.g., that we have metadata is based on an assumption that we will have good

Re: [Bro-Dev] package manager progress

> On Jul 28, 2016, at 3:37 PM, Robin Sommer wrote: > >> in favor of auto-installing the python dependencies into Bro’s install >> prefix. > > I also prefer auto-installation, unless there's a reasonable risk that > it could interfere with already installed versions of those

Re: [Bro-Dev] package manager progress

On Thu, Jul 28, 2016 at 17:52 +, you wrote: > I think still allowing package sources to be structured in a directory > hierarchy is more intuitive to navigate and maybe less intimidating to > modify than a single file as the source grows over time. And I’m > already using INI format in 2

Re: [Bro-Dev] package manager progress

> On Jul 27, 2016, at 6:37 PM, Robin Sommer wrote: > > On the other hand, if, for example, somebody ends up > browsing the package source repository on GitHub, I'm sure they'd be > confused by all the packages pointing to very old versions. Yeah, agree that is confusing and a

Re: [Bro-Dev] package manager progress

> - Would suggest to rename “pkg.meta” to, say, “bro-pkg.meta”, just to > make it more explicit that it's a Bro package. That's something one > can also then search for on GitHub. Just throwing in two more permutations: bro.meta or bro.pkg. > - For our default package source, do we want to

Re: [Bro-Dev] package manager progress

> On Jul 27, 2016, at 12:15 PM, Johanna Amann wrote: > > And to add a me three to this - I am also with him on this one. On top of > things - I might misremember this, but didn't we plan package names to > include the github user name at one point of time? So a package name

Re: [Bro-Dev] package manager progress

On Sun, Jul 24, 2016 at 19:45 +, you wrote: > The package manager client is at a point now where I think it would be > usable. Finally got a chance to play with it a bit. Excellent work, I really like it! Belows a list of just smaller things I noticed. The only larger question I have is

Re: [Bro-Dev] package manager progress

> On Jul 27, 2016, at 12:59 PM, Robin Sommer wrote: > > Ah, I see. Would it be better to generally use the full path as the > name, and not search for submatches, to make it consistent/unambiguous > what a name refers to? At least from my usage it’s been convenient to be able

Re: [Bro-Dev] package manager progress

Make it four. :) I'm with Seth, too, better not to enforce any naming scheme because the boundaries are unclear. Also, note that a single binary Bro plugin can provide multiple quite different things (say, a reader and an analyzer and a packet source all at the same time, if one so desires :).

Re: [Bro-Dev] package manager progress

> On Jul 27, 2016, at 11:15 AM, Johanna Amann wrote: > > And to add a me three to this - I am also with him on this one. On top > of things - I might misremember this, but didn't we plan package names > to include the github user name at one point of time? So a package name

Re: [Bro-Dev] package manager progress

And to add a me three to this - I am also with him on this one. On top of things - I might misremember this, but didn't we plan package names to include the github user name at one point of time? So a package name would be user/redis, for example, and there also could be user2/redis? Johanna

Re: [Bro-Dev] package manager progress

> I actually don't like this that much because some of these can cross > boundaries and do all sorts of different things in a single plugin. > It makes more sense to me to leave the naming open. I'm with Seth on this one. The reason why I think we should keep the naming open is that it's the

Re: [Bro-Dev] package manager progress

> On Jul 27, 2016, at 11:44 AM, Seth Hall wrote: > > >> On Jul 25, 2016, at 4:49 PM, Azoff, Justin S wrote: >> >> In one aspect the pktsrc- prefix acts like a tag, but can also help >> disambiguate plugins... i.e., a redis log writer plugin vs. a redis

Re: [Bro-Dev] package manager progress

> On Jul 25, 2016, at 4:49 PM, Azoff, Justin S wrote: > > In one aspect the pktsrc- prefix acts like a tag, but can also help > disambiguate plugins... i.e., a redis log writer plugin vs. a redis data > store plugin vs. a redis protocol analyzer. I actually don't like

Re: [Bro-Dev] package manager progress

> > I'm not 100% following. Isn't every package recorded as submodule? > > Every package within a package source is recorded as a git submodule > and that recording happens at the time the package author registers > their package with a source. The bro-pkg client itself makes no > changes to

Re: [Bro-Dev] package manager progress

> On Jul 25, 2016, at 10:31 PM, Matthias Vallentin wrote: > >> 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

Re: [Bro-Dev] package manager progress

> 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'm not 100% following. Isn't

Re: [Bro-Dev] package manager progress

> On Jul 24, 2016, at 3:45 PM, Siwek, Jon wrote: > > * Add a way for package’s to define “discoverability metadata”. Kind of related to this, I think we need to define some basic rules for package naming. This can help discoverability and also namespacing issues. Right

Re: [Bro-Dev] package manager progress

> On Jul 25, 2016, at 10:18 AM, Matthias Vallentin 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 >>

Re: [Bro-Dev] package manager progress

> On Jul 25, 2016, at 6:53 AM, Jan Grashöfer 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

Re: [Bro-Dev] package manager progress

> 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

Re: [Bro-Dev] package manager progress

Amazing work! I really like the package manager and I am looking forward to contributing a script. > * 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

[Bro-Dev] package manager progress

The package manager client is at a point now where I think it would be usable. Documentation is here: https://bro.github.io/package-manager/ There is a branch in the ‘bro’ repo called ‘package-manager’ that simply changes CMake scripts to install ‘bro-pkg’ along with bro. Here’s an example