Re: [Bro-Dev] Package manager meta data

On Tue, Nov 29, 2016 at 17:42 +, you wrote: > The metadata changes discussed in this thread are now in bro-pkg 0.8 I've tried this out now, it's all working great, thanks! I just noticed one tiny little thing, for which I filed a ticket: https://bro-tracker.atlassian.net/browse/BIT-1766

Re: [Bro-Dev] Package manager meta data

The metadata changes discussed in this thread are now in bro-pkg 0.8 (and the structure of the bro/packages source on GitHub is adapted for it). - Jon ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] Package manager meta data

Thanks, that and the new text help, I think I got it now. That all makes sense. Maybe add to the text that tags are not pushed by default by git, so one shouldn't forget "git push --tags". Robin On Mon, Nov 21, 2016 at 18:24 +, you wrote: > > > On Nov 21, 2016, at 10:38 AM, Robin Sommer

Re: [Bro-Dev] Package manager meta data

> On Nov 21, 2016, at 10:38 AM, Robin Sommer wrote: > > On Mon, Nov 21, 2016 at 15:53 +, you wrote: > >> When selecting a version, `bro-pkg update` only considers newer x.y.z >> release tags for that package. When selecting a branch, it tracks >> updates along that branch.

Re: [Bro-Dev] Package manager meta data

On Mon, Nov 21, 2016 at 15:53 +, you wrote: > When selecting a version, `bro-pkg update` only considers newer x.y.z > release tags for that package. When selecting a branch, it tracks > updates along that branch. Ok, sounds like I should think about it not as "master" then, but as "HEAD

Re: [Bro-Dev] Package manager meta data

> On Nov 20, 2016, at 1:57 PM, Robin Sommer wrote: > > What will be the relationship between version tags and the master > branch? Is master just another version I can select to install? Yes, any tag or branch can be selected with `bro-pkg install —version `. When selecting a

Re: [Bro-Dev] Package manager meta data

On Fri, Nov 18, 2016 at 20:57 +, you wrote: > Here’s a summary of the set of changes I plan to make related to > package metadata, let me know if there’s objections or alternate > ideas: Sounds all good to me. That should make the Python API easier to use for accessing meta information, too.

Re: [Bro-Dev] Package manager meta data

Here’s a summary of the set of changes I plan to make related to package metadata, let me know if there’s objections or alternate ideas: 1) remove mentions of ‘version' field from bro-pkg.meta as versioning is done entirely by git tags 2) packages should now put ‘description’ and ‘tags' fields

Re: [Bro-Dev] Package manager meta data

> On Oct 31, 2016, at 12:41 PM, Jan Grashöfer wrote: > >> Theoretically, if the package was just temporarily unavailable, the next >> time the aggregation process runs, it would get listed again > > How, if it is completely removed? Oh, duh, I see what you mean. I

Re: [Bro-Dev] Package manager meta data

> I was thinking that even the upstream source repo could clean out invalid > packages automatically since their metadata/listing is no longer useful to > anyone. Did you have more thoughts/concerns about why that might require > manual interaction? I just don't get this: > Theoretically, if

Re: [Bro-Dev] Package manager meta data

> On Oct 31, 2016, at 12:03 PM, Jan Grashöfer wrote: > > I thought about supporting the operator of the > upstream source repository in cleaning the repo. However, this will > require manual interaction anyway and hopefully isn't a use case that > will be encountered

Re: [Bro-Dev] Package manager meta data

>> Thanks for the clarification. Automatic removal might be a bit >> aggressive but a warning would be very helpful I guess. > > From the user’s perspective, if they already installed a package that later > becomes unavailable, they’d see a warning when they do “refresh”, but > otherwise they

Re: [Bro-Dev] Package manager meta data

> On Oct 30, 2016, at 6:20 PM, Jan Grashöfer wrote: > > What about the "info" command? If a package is not installed it would be > nice if the command would obtain the latest meta data from the package's > repository as well. Yep, I imagined “info” would still grab

Re: [Bro-Dev] Package manager meta data

> Aggregating it into the package source is a better solution than having every > client do it. The later isn’t going to scale well: the client will take > longer and longer over time as more and more packages get registered to a > source. Also takes longer as a function of total number of

Re: [Bro-Dev] Package manager meta data

On Sat, Oct 29, 2016 at 11:28 -0700, I wrote: > (if a source operator can do hooks that will avoid any delays at all). Ah, that's not true of course, it only applies to initial setup of a package. Robin -- Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin

Re: [Bro-Dev] Package manager meta data

I'll just jump in at the end of the thread: Switching to fully self-describing packages sounds great to me, that should solve all the issues I noticed. I also don't quite recall the reasoning for arriving at the current scheme, but it was probably a combination of iterating over the design a few

Re: [Bro-Dev] Package manager meta data

> On Oct 28, 2016, at 5:52 PM, Jan Grashöfer wrote: > > Correct me if I am wrong > but bro-pkg.meta contains stuff like script_dir and dependencies (so > rather technically), whereas bro-pkg.index contains the descriptive > information like info text and tags (which is

Re: [Bro-Dev] Package manager meta data

> That could be misleading. The purpose of putting those tags in bro-pkg.index > is because they are related to package “discoverability” and it’s easier to > search that data if it’s located in a single repo, the package source, rather > than having to download the entire universe of packages

[Bro-Dev] Package manager meta data

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