# script loading changes **URL:** \ **Category:** Development\ **Tags:** development\ **Created:** [July 12, 2011, 10:26pm UTC](https://community.zeek.org/t/script-loading-changes/1922 "2011-07-12T22:26:24Z")\ **Posts on this page:** 10\ **Page:** 2
**Author:** ![Seth\_Hall3](https://avatars.discourse-cdn.com/v4/letter/s/d6d6ee/32.png) [@Seth\_Hall3](https://community.zeek.org/u/Seth_Hall3)\ **Post date:** [July 14, 2011, 1:12am UTC](https://community.zeek.org/t/script-loading-changes/1922/21 "2011-07-14T01:12:09Z")
> The problem we're trying to solve is how to best organize the packages > under protocol/ such that there's a way to load them without a possibly > unwanted side-effect of loading an entire package under frameworks/ > because one script happens to require it (is that right Seth?). Correct. > e.g. we want "@load protocols/http" to avoid loading frameworks/software. > > Why don't we just write the \_\_load\_\_.bro manifest of the package to not > @load scripts that may have unwanted side effects? The \_\_load\_\_.bro that > gets loaded implicitly is already provided only for convenience and may > not actually load the entire contents of the package. The \_\_load\_\_.bro scripts are actually where I would be hiding these extra dependency based loads. I was just looking for a way to reduce dependencies without having to add code to manage things manually. For example, I'd like packages to offer the ability to do something with the software framework if it's available, but if it's not available to just not load the functionality. I'm starting to recognize that I'm looking to do something like dependency injection but perhaps we're still a bit early on in the modularization of Bro scripts for us to figure out how to do this well. If everyone's onboard we can just table this discussion for now and I can do this more manually, I may even be able to rig up a dependency injection-like framework in script-land. I would still really like the relative path based loading though, it's really painful to do inter-directory script loading right now and it would be a bit difficult for others to contribute external scripts and manage them well because the full path is used for loading. > 3) the "I don't care how much extra stuff gets loaded, give me everything >   in the package" approach via "@load protocols/http/\*" to recursively >   load all files that have a .bro extension (skipping \_\_load\_\_.bro) I'm not sure this is a good option as I have written a couple of things where you would never want to load everything and loading everything could actually lead to disaster (or at least broken-ness). 🙂   .Seth ---
**Author:** ![Jonathan\_Siwek](https://avatars.discourse-cdn.com/v4/letter/j/e68b1a/32.png) [@Jonathan\_Siwek](https://community.zeek.org/u/Jonathan_Siwek)\ **Post date:** [July 14, 2011, 2:37am UTC](https://community.zeek.org/t/script-loading-changes/1922/22 "2011-07-14T02:37:54Z")
> example, I'd like packages to offer the ability to do something with > the software framework if it's available, but if it's not available to > just not load the functionality. It seems like that approach is well-intended at making packages appear more modular, but weren't the solutions we came up with taking away from a user's ability to control what scripts get loaded? For example, what if a user wants the ssh package's software-related scripts to load, but not the http package's software-related scripts? > I'm starting to recognize that I'm looking to do something like > dependency injection Dependency injection patterns are more for object-oriented languages, no? > but perhaps we're still a bit early on in the > modularization of Bro scripts for us to figure out how to do this > well. If everyone's onboard we can just table this discussion for now Yeah, we might wait. I'm not fully convinced that the way you currently organized things actually has a modularity problem that significantly hinders a user's ability to use bro. > I would still really like the relative path based loading though Yeah, I didn't have any problems with that new feature. - Jon ---
**Author:** ![Seth\_Hall3](https://avatars.discourse-cdn.com/v4/letter/s/d6d6ee/32.png) [@Seth\_Hall3](https://community.zeek.org/u/Seth_Hall3)\ **Post date:** [July 14, 2011, 3:14am UTC](https://community.zeek.org/t/script-loading-changes/1922/23 "2011-07-14T03:14:20Z")
> It seems like that approach is well-intended at making packages appear > more modular, but weren't the solutions we came up with taking away > from a user's ability to control what scripts get loaded? > For example, what if a user wants the ssh package's software-related > scripts to load, but not the http package's software-related scripts? Yep, agreed on both counts. I had kind of identified the "globally enabled functionality" problem myself internally, but was reluctant to admit it to myself because in the case of the software scripts it should cause very little overhead. It does cry out for a more generic solution though that leaves control in the users hands. > Dependency injection patterns are more for object-oriented languages, no? Yeah, I think you're right. 🙂 > > but perhaps we're still a bit early on in the > > modularization of Bro scripts for us to figure out how to do this > > well. If everyone's onboard we can just table this discussion for now > > Yeah, we might wait. I'm not fully convinced that the way you currently > organized things actually has a modularity problem that significantly > hinders a user's ability to use bro. At least we're slowly getting somewhere and sometimes by choosing \*not\* to do things. 🙂   .Seth ---
**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:** [July 14, 2011, 4:45am UTC](https://community.zeek.org/t/script-loading-changes/1922/24 "2011-07-14T04:45:26Z")
Sorry for being the party pooper now but I \*do\* like the ability to load something automatically (only) when something else is loaded as well. I don't think that can really be substituted for at the scripting layer right now, at least not nicely. software.bro is a good application for that and I'm sure there are more (like the intelligence framework?). We need to bring the current prefix mechanism back to live anyway (and with the new load order I think), and this would be quite easy to add on top of that if I'm not missing anything. So why don't we give it a try and see if it works for what's it's supposed to help with. Robin ---
**Author:** ![Seth\_Hall3](https://avatars.discourse-cdn.com/v4/letter/s/d6d6ee/32.png) [@Seth\_Hall3](https://community.zeek.org/u/Seth_Hall3)\ **Post date:** [July 14, 2011, 4:53am UTC](https://community.zeek.org/t/script-loading-changes/1922/25 "2011-07-14T04:53:55Z")
> Sorry for being the party pooper now but I \*do\* like the ability to > load something automatically (only) when something else is loaded as > well. Haha, I don't think it's possible for you to be the Bro party pooper. You're the life of the party! > I don't think that can really be substituted for at the > scripting layer right now, at least not nicely. I'll think about this. It may be possible to make something fairly clean at the scripting layer. > software.bro is a good > application for that and I'm sure there are more (like the > intelligence framework?). Yep, the intelligence framework is another big one. The metrics framework may be another one as well, but possibly not. I'm not sure of how exactly it will be used yet. .Seth ---
**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:** [July 14, 2011, 4:58am UTC](https://community.zeek.org/t/script-loading-changes/1922/26 "2011-07-14T04:58:19Z")
Ok, if you can come up with something nice, I'm all fine. 🙂 Robin ---
**Author:** ![Jonathan\_Siwek](https://avatars.discourse-cdn.com/v4/letter/j/e68b1a/32.png) [@Jonathan\_Siwek](https://community.zeek.org/u/Jonathan_Siwek)\ **Post date:** [July 14, 2011, 3:03pm UTC](https://community.zeek.org/t/script-loading-changes/1922/27 "2011-07-14T15:03:12Z")
> We need to bring the current prefix mechanism back to live anyway > (and with the new load order I think), and this would be quite easy to add > on top of that if I'm not missing anything. In my mind I saw the new implementation of @prefixes as independent of that "@add x when y" idea. There's some similarities in how they work, but they don't depend on each other. > So why don't we give it a try For now I'll attempt these changes: - allow relative paths in @load's, e.g. "@load ./software" - new @prefixes implementation I'll put these off due to contention: - allowing '.' vs. '/' in package names - "@add x when y" ---
**Author:** ![Seth\_Hall3](https://avatars.discourse-cdn.com/v4/letter/s/d6d6ee/32.png) [@Seth\_Hall3](https://community.zeek.org/u/Seth_Hall3)\ **Post date:** [July 14, 2011, 3:14pm UTC](https://community.zeek.org/t/script-loading-changes/1922/28 "2011-07-14T15:14:43Z")
That sounds good to me.   .Seth ---
**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:** [July 14, 2011, 3:41pm UTC](https://community.zeek.org/t/script-loading-changes/1922/29 "2011-07-14T15:41:53Z")
> "@add x when y" idea. There's some similarities in how they work, but they > don't depend on each other. That's right, they don't depend on each other. I was just thinking that doing the @add doesn't require much in addition. > For now I'll attempt these changes: Ok. Robin ---
**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:39pm UTC](https://community.zeek.org/t/script-loading-changes/1922/30 "2022-05-06T15:39:39Z")
Closed on May 6, 2022, 3:39pm UTC [Previous page](https://community.zeek.org/t/script-loading-changes/1922.md?page=1)