To find the new name for our CBAN project, it probably make sense to
brainstorm separately from the existing technical thread. I'd say let's
collect some candidates and then create survey to vote on them.
Here are some ideas from the existing thread:
- brow
- broil
- broom
- bpk
- berk
- bob
- bip
Looking forward to hear your ideas.
Matthias
I don't have much of an opinion in the naming, just that we should avoid using a name that already exists.
I checked for collisions in debian(package names and filenames under *bin/) the only tool that currently exists is 'bip' which is an irc proxy.
There is a chef related tool called berkshelf: https://github.com/berkshelf/berkshelf which installs a 'berks' command
One thing that did come up was this:
https://github.com/CompEvol/CBAN: Comprehensive BEAST Archive Network
which doesn't seem terribly popular, but is actively in use.
bpkg is another obvious name that is already in use: https://github.com/bpkg
Just my opinion…
I like how Spicy was named, by choosing something completely different and unrelated to the “bro” theme.
Or call it frat house.
-AK
I like how Spicy was named, by choosing something completely different and
unrelated to the "bro" theme.
I like that too. Do you have a suggestion?
Matthias
Oh man. I don’t know. Call it the colossal.
-AK
Besides naming and skipping ahead to implementation, I highly recommend looking at how Rust manages crates. They are a pleasure to use and work with.
-AK
Think the current name is fine, but if you change it I think it helps if it relates to things people know. So names like bpkg, bro-ports, or bro-brew would give the immediate analogy through the name.
Think the current name is fine, but if you change it I think it helps if it relates to things people know. So names like bpkg, bro-ports, or bro-brew would give the immediate analogy through the name.
True. That's why I somehow like brow. It relates to the logo and is
memorable but could also be seen as a merge of bro-brew.
By the way: Are we talking about renaming the whole project? I already
get used to CBAN and calling the project CBAN does not necessarily imply
that e.g. the CBAN-client could be named brow (although that might make
things not that intuitive).
Best regards,
Jan
Besides naming and skipping ahead to implementation, I highly recommend
looking at how Rust manages crates. They are a pleasure to use and work
with.
Rust's cargo [1] is indeed well thought through (I like the dependency
specification especially [2]) and we should look at it in depth during
the design.
We already have a very detailed technical thread, that's why I'd like
this thread to remain on the naming aspect. The rust folks chose
cargo/crate for their package manager vocabulary. I think we should also
put some effort in it, although I don't see the need to find synonyms or
other fancy words for package management.
Matthias
[1] Page Moved
[2] Page Moved
By the way: Are we talking about renaming the whole project?
I don't know :-). We need a command line client and a project name. When
they are the same, it's certainly easier to remember.
My favorite name so far is also "brow." The eye brow of the Bro logo
makes for a nice association. It didn't occur to me until you mentioned
it, but it's also only edit distance one away from "brew," which helps
in creating a package manager association.
Matthias
I don’t like the name CBAN, for a number of reasons.
The are a number of C?AN’s out there. I believe that CTAN was the first one (TeX), and then CPAN (Perl), CRAN (R), and CEAN (Erlang) followed. The architecture of CPAN was also ported for CCAN (C) and JSAN (Javascript).
Because these all share a family tree, much of the nomenclature is the same. Terms such as “packages,” “modules,” and “distributions” mean something specific in these cases, and those don’t map well to Bro terminology. The other consistency is that most C?AN’s don’t actually have a command line client - Perl seems to be the notable exception, and its command line client is awful.
I think one of the main reasons people like CBAN is because they assume people will liken it to CPAN and immediately understand what it does. That might be the case for people who have Perl experience (although I’ll argue that the number of those people is declining), but users with CTAN, CRAN, or CCAN experience will come in with completely different assumptions. Even people who do liken it to CPAN will need to reframe their assumptions, since the similarities don’t extend very far.
So essentially, the impact of the name CBAN on people who are unfamiliar with it would be one of: 1) haven’t heard of C?AN, don’t understand what it does, 2) have heard of CPAN, assume a similar model and a similar (awful) command line client, or 3) have heard of a different C?AN, assume they have to download “packages” from the website manually, or 4) have heard of CPAN and some other C?AN, have no idea what to assume.
I also don’t think the acronym CBAN represents the goals of the project:
Comprehensive - I don’t think we can come close to claiming that. If the project was hunting for Bro scripts that others have shared and aggregating them somehow, then I think we could claim that it’d be comprehensive, but that seems like a weird claim when submissions are voluntary.
Bro - No arguments here. 
Archive - I’m not sure what this means in this context. Does it mean that plugins are distributed as archives? I’m not sure this makes sense to do. I think this is a holdover from the days before distributed VCS and GitHub, when you could download an archive of the packages. While I think we will offer that functionality, I don’t think that is or should be a key feature.
Network - Again, not really sure what this means. To me, this implies a distributed model, which I don’t think this project will offer – at least not for a while.
Finally, from the strictly practical perspective:
–Vlad
I don't know :-). We need a command line client and a project name. When
they are the same, it's certainly easier to remember.
Yes, I think the client and project name should be the same. From the other thread, I take it we also need a term to use as a substitute for “package” ?
Misc. ideas for both client/project name as well as term to use for “package”:
- boxer, boxes (sort of already taken by Broala's BroBox)
- bundler, bundles (though seems like Ruby has taken this name)
- bagger/bagboy, bags (also has the association w/ eye bags)
- tempest, drops (eye of the storm, rain drops, eye drops... the tears of those trapped in dependency-hell?)
I favor “bagger” or “bagboy” along with “bags”. It’s charming/amusing, easily logo-able, and is a nice change from away from the usual motifs related to eyes or puns related to “what words are there that start with b, r, o?”. They also work as analogies for the process the command line client will perform and for indicating that bags are not just filled with one type of thing. e.g. bags may contain any combination of scripts, BIFs, or native plugins/code, like grocery bags may contain various types of food.
Should also consider how easy it is to stick the word Bro in front of it when trying to associate it w/ the main Bro project. i.e. “Bro’s Bagboy”, “Bro Bagger” and “Bro Bag” I find easy enough to say.
My favorite name so far is also "brow." The eye brow of the Bro logo
makes for a nice association. It didn't occur to me until you mentioned
it, but it's also only edit distance one away from "brew," which helps
in creating a package manager association.
I also like “brow” the best (of other people’s ideas), but still don’t like it that much. While it is clever that “brow" both starts with “bro” and is related to eyes, it also feels predictable.
- Jon
- boxer, boxes (sort of already taken by Broala's BroBox)
- bundler, bundles (though seems like Ruby has taken this name)
- bagger/bagboy, bags (also has the association w/ eye bags)
- tempest, drops (eye of the storm, rain drops, eye drops... the tears of those trapped in dependency-hell?)
Of those, I like "bag" the best to represent a package that can be a
"mixed bag" of scripts and compiled code. My second vote goes for
"bundle," which is also something quite intuitive for a package. The
remaining ones take a bit more think time (at least for me) to map to
something package related.
I favor “bagger” or “bagboy” along with “bags”.
I did not get the "bagger" and "bagboy" variations until I googled it,
probably because I'm not a native speaker. However, I like the grocery
bag association, that one stuck immediately. We could have a shopping
"cart" as well, to represent a collection of bags. The grocery store
theme works really well, in my opinion.
Matthias
I like the bagging theme, too. As one more thought, maybe the client
could just be "bag" as well? It's a verb too. 
Can we call an orphaned package or homeless one a “bag lady"?
Think the current name is fine, but if you change it I think it helps if
it relates to things people know. So names like bpkg, bro-ports, or
bro-brew would give the immediate analogy through the name.
I like all these suggestions from Adam - and as a person who enjoys making
electronic music would humbly add 'bpm' (Bro Package Manager) to the list
greg
I like all these suggestions from Adam - and as a person who enjoys making
electronic music would humbly add 'bpm' (Bro Package Manager) to the list
We had a good discussion in the Bro Gitter channel about this
yesterday. In fact, I suggested "bpm," but as it turns out, there
exists already a package that installs a PREFIX/bin/bpm executable.
To summarize the discussion: the sentiment was that calling things
"packages" is the least unexpected from a user point of view, because
many other package managers (e.g., Python's pip) also use the term
"package" for script and compiled code.
Matthias
I have gone over a bunch of these threads and want to bring this back towards consensus, or at least consilience. Let’s pick from the following 5 options, and then we can decide if these are bundles, ports, packages, plugins, extensions, modules, or bags.
Key criteria are clarity and simplicity. Does it give an intuitive sense of what it is without adding confusion? No name or analogy will be perfect, but let’s not let the perfect be the enemy of the good.
And the nominees are:
1. bpkg
2. brow
3. bagger
4. bro-ports
5. bro-brew
After talking with Matthias the other day I think the best option is simply:
6. bro-package or bro-pkg
We already have things like bro-cut, and bro-aux. Broctl pretty close to bro-ctl.
These are variants of #1, which I now substitute with bro-pkg