# bro-pkg v0.3

**URL:** <https://community.zeek.org/t/bro-pkg-v0-3/4304>\
**Category:** Development\
**Tags:** development\
**Created:** [August 12, 2016, 11:54pm UTC](https://community.zeek.org/t/bro-pkg-v0-3/4304 "2016-08-12T23:54:47Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Siwek\_Jon](https://avatars.discourse-cdn.com/v4/letter/s/90db22/32.png) [@Siwek\_Jon](https://community.zeek.org/u/Siwek_Jon)\
**Post date:** [August 12, 2016, 11:54pm UTC](https://community.zeek.org/t/bro-pkg-v0-3/4304/1 "2016-08-12T23:54:47Z")

</div>

Feedback from the previous bro-dev thread is now addressed and I’d consider this version of the package manager ready for people to start trying out. Documentation:

[http://bro-package-manager.readthedocs.io/](http://bro-package-manager.readthedocs.io/)

Notes/questions:

\* Docs are now hosted at Read the Docs instead of GitHub

I found it more straightforward to setup/use/maintain docs on RtD. It automatically builds docs upon committing to master or making a release tag. See [1] for directions on how the docs could be made reachable at a [bro.org](http://bro.org) domain, but still hosted at RtD.

\* A package submission process is found in the README of [https://github.com/bro/packages](https://github.com/bro/packages)

Which is just my idea of what the process will look like, so please comment if it differs from anyone’s expectations.

\* I’ve put it on PyPi [2] and it’s installable via `pip`

What are thoughts on making this the standard installation process for bro-pkg instead of bundling it into the Bro distribution? Benefits:

1) Decoupling from Bro’s release cycle. Seems like the kind of tool where it’s important to have quick/lightweight releases/patches that are easy for users to upgrade to. Would bundling in with Bro make for a more cumbersome upgrade path?

2) Installing via pip will automatically install dependencies (gitpython, semantic-version). Installing those automatically via Bro’s CMake, while probably possible, seems unusual/hacky.

A downside would be that the first-time configuration is currently easier if done via Bro’s CMake since it can fill in all the paths of bro-pkg.config automatically. But I also see potential for addressing that in a way that doesn’t involve putting bro-pkg into Bro’s CMake. E.g. if there were `bro —config site_dir` and `bro —config plugin_dir` commands that could be executed from the command-line, bro-pkg could just use those to autogenerate an appropriate config.

- Jon

[1] [http://read-the-docs.readthedocs.io/en/latest/alternate\_domains.html](http://read-the-docs.readthedocs.io/en/latest/alternate_domains.html)  
[2] [https://pypi.python.org/pypi/bro-pkg](https://pypi.python.org/pypi/bro-pkg)

---

<div class="post-metadata">

**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\
**Post date:** [August 15, 2016, 3:20pm UTC](https://community.zeek.org/t/bro-pkg-v0-3/4304/2 "2016-08-15T15:20:21Z")

</div>

> [http://bro-package-manager.readthedocs.io/](http://bro-package-manager.readthedocs.io/)

Nice! I like the Quickstart guide, that works now. The How-Tos are  
great, too. One suggestion for "Create a Package": I believe the text  
doesn't really say anywhere yet explicitly that a plugin can contain  
these three different things. Maybe add paragraph summarizing what  
"package" actually means at the beginning?

> \* A package submission process is found in the README of [GitHub - bro/packages: The default package source of the Bro Package Manager](https://github.com/bro/packages)

That sounds all good to me. One nit: In (2): the "this" before  
repository is ambiguous because (1) talks about a different one.

Looks like this the location where we can also require a couple more  
pieces of meta data. I still vote for keeping this minimal, but I  
suggest we require at least an email contact and a license statement  
before accepting a pull request. I'm torn on requiring a version  
number as well: I would like too, but we can't enforce that people  
update it as they make changes; and it would just be useless if people  
don't. So probably better to skip.

Once this is finalized, do you plan to add a pointer back here from  
the BPM docs?

> What are thoughts on making this the standard installation process for  
> bro-pkg instead of bundling it into the Bro distribution? Benefits:

Yeah, I agree, that makes sense. pip is the standard way to install  
Python stuff and really straight-forward.

> E.g. if there were `bro —config site_dir` and `bro —config plugin_dir`

Good thought, though why not keep it out of Bro: we can add a script  
"bro-config" to Bro that cmake populates with the right data. That  
would actually be helpful for other stuff as well. That's something we  
could still add for 2.5, too.

Robin

---

<div class="post-metadata">

**Author:** ![Siwek\_Jon](https://avatars.discourse-cdn.com/v4/letter/s/90db22/32.png) [@Siwek\_Jon](https://community.zeek.org/u/Siwek_Jon)\
**Post date:** [August 15, 2016, 6:36pm UTC](https://community.zeek.org/t/bro-pkg-v0-3/4304/3 "2016-08-15T18:36:37Z")

</div>

> One suggestion for "Create a Package": I believe the text  
> doesn't really say anywhere yet explicitly that a plugin can contain  
> these three different things. Maybe add paragraph summarizing what  
> "package" actually means at the beginning?

Done.

> > \* A package submission process is found in the README of [GitHub - bro/packages: The default package source of the Bro Package Manager](https://github.com/bro/packages)
> 
> That sounds all good to me. One nit: In (2): the "this" before  
> repository is ambiguous because (1) talks about a different one.

Changed.

> Looks like this the location where we can also require a couple more  
> pieces of meta data. I still vote for keeping this minimal, but I  
> suggest we require at least an email contact and a license statement  
> before accepting a pull request.

Yeah, makes sense to put those bits in the index data, if you decide to require them.

> I'm torn on requiring a version  
> number as well: I would like too, but we can't enforce that people  
> update it as they make changes; and it would just be useless if people  
> don't. So probably better to skip.

I agree. We depend on git being the authority for versioning anyway, so requiring people to update a metadata file in addition to creating a git tag still borders on useless even as an enforced rule.

> Once this is finalized, do you plan to add a pointer back here from  
> the BPM docs?

There was one in the main README/landing-page. I added another link in the “Registering to a Package Source” walkthrough. Let me know if there was another place you were expecting to see it, but didn’t.

> > E.g. if there were `bro —config site_dir` and `bro —config plugin_dir`
> 
> Good thought, though why not keep it out of Bro: we can add a script  
> "bro-config" to Bro that cmake populates with the right data. That  
> would actually be helpful for other stuff as well. That's something we  
> could still add for 2.5, too.

Good idea. I’ll get a branch for that today/tomorrow.

- Jon

---

<div class="post-metadata">

**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\
**Post date:** [August 16, 2016, 4:57pm UTC](https://community.zeek.org/t/bro-pkg-v0-3/4304/4 "2016-08-16T16:57:07Z")

</div>

Ah, missed that. I think we need to state that more explicitly and  
give some more context about this repo being the central hub for the  
community to share scripts. Although not sure if the BPM docs are  
actually the right place for that then, should that go into the  
community section on [bro.org](http://bro.org)?

Robin

---

<div class="post-metadata">

**Author:** ![Siwek\_Jon](https://avatars.discourse-cdn.com/v4/letter/s/90db22/32.png) [@Siwek\_Jon](https://community.zeek.org/u/Siwek_Jon)\
**Post date:** [August 16, 2016, 6:51pm UTC](https://community.zeek.org/t/bro-pkg-v0-3/4304/5 "2016-08-16T18:51:09Z")

</div>

The “contributing” section [1] feels like one place to put it. Even looks like there’s an old reference to the project there that needs to be updated. I can do that now, but should I add a temporary disclaimer that it’s “not yet open for submissions” or would it be alright at this point if a person came across it and tried to submit a package?

- Jon

[1] [https://www.bro.org/community/index.html#contributing-tobro](https://www.bro.org/community/index.html#contributing-tobro)

---

<div class="post-metadata">

**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\
**Post date:** [August 16, 2016, 7:35pm UTC](https://community.zeek.org/t/bro-pkg-v0-3/4304/6 "2016-08-16T19:35:57Z")

</div>

Let's wait until we're ready to announce it. A blog posting would be  
good once we believe we have the process down. Before we do that,  
maybe we can get a couple people here on this list to give publishing  
some of their scripts a try? If that goes well, we start over once  
more and announce.

Robin

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex011/uploads/zeek/original/1X/f09d732bc2cc7c7cc7e35db67cf4e1d5233ce7a7.png) [@system](https://community.zeek.org/u/system)\
**Post date:** [May 6, 2022, 3:43pm UTC](https://community.zeek.org/t/bro-pkg-v0-3/4304/7 "2022-05-06T15:43:57Z")

</div>


