Added the fix two: convoy, perdix.
I like convoy, but it also suffers from the issue of being taken for another project already.
Iâll remove it to spare people of considering it in vein.
Too suggestive? We donât want anything with problematic connotations.
2 Likes
Well itâs suggestive of camels.
2 Likes
Not without the camel context.
1 Like
Which is implied when the topic is OCaml?
A command name is readily viewed as a verb. The verb form of âhumpâ has problematic connotations. There is no camel-related verb form for the wordâleast none thatâs well known in English.
Even if the command names didnât suggest verbs, and even in a camel context, some people would hear the other connotation routinely, I believe. (âCaml humpâ doesnât work that way because âcamelâ is explicit in the phrase, and âcamel humpâ is a common phrase used to refer to, of course, the humps on camelsâ backs.)
1 Like
Alright, whatever. Some suggestions are better than hump imo but I thought it was a good idea to reuse a previously used name, which somehow managed to not offend anyone for years.
We might want to remove the problematic word âpackageâ too.
Itâs not really a verb, in case of (former) jbuilder, and people forget it, as I may see from different suggestions. Since jbuilder provides a subcommand interface it should be a noun, e.g.,
jbuilder build
jbuilder install
Moreover, since jbuilder doesnât require the subject (it is implicit - the current working directory), the name of the tool should be ideally the subject, e.g.,
ocaml-project build
It could be less direct, i.e., instead of using ocaml-project we can rely on some metaphor of a project. The idea of using a metaphoric notion of a subject is to ease the memorization of commands. Basically, they should sound natural, e.g.
caravan build
caravan run
caravan pack
caravan deploy
To summarize, when a new name is devised, we should consider how it will look from the user perspective. Now how long it is or how its funny. It should be chosen without considering the rest of the interface.
Ah, sorry, Iâve picked your phrase out of the context. Indeed, I agree, that just typing hump would be readily viewed as a verb. Of course, hump build reads differently, but as soon as the subcommand become a noun, e.g., hump utop, poor utop.
P.S. Actually I even started to read hump build as a verb-noun, since build could be a noun also, that means âbuild artifactâ
1 Like
bjuilder⊠
3 Likes
mjolnir, after Mjölnir, the hammer of Thor.
ââŠwhatsoever might be before him, and the hammer would not fail; and if he threw it at anything, it would never missâŠâ (Prose Edda)
The name is almost certain to complete from âmjâ on a Unix-like system.
1 Like
Another theme we could explore is âbutlerâ. Itâs kind of the job of jbuilder: we give jbuilder high level information and orders and it takes care of everything. And I think think it works well as a command line tool:
$ butler build
$ butler install
$ butler deploy
...
I guess this description is true for a lot of tool though. One idea would be just db for Development Butler.
3 Likes
An executable named âdbâ on unix systems ? You really want sysadmins to commit suicide, donât you ? 
(I remember a very general purpose tool called butler, but I donât remember where)
4 Likes
Do not name a Unix executable âdbââŠ
2 Likes
jeeves or (alfred / pennyworth) would also be a good name with the butler theme.
Yh, db is a bad idea indeed.
While I was looking for other ideas, I found this http://www.pitt.edu/~dash/mbuilder.html and in particular the story of the builder Zi. Itâs about a dwarf who constructs a church really fast. The ending is not great but otherwise that would be a nice short name
1 Like
Itâs now settled: Jbuilder will be renamed Dune.
Thanks to everyone for helping in finding a new name for Jbuilder! I personally loved the dune books and Iâm looking forward to this rename, I think itâs a great choice for Jbuilder.
Weâll start the renaming work at the beginning of next year, you can follow the advancement on this ticket. Dune will be the first non-beta release of the project.
Jbuilder has gone a long way since itâs initial alpha release in December 2016, and I hope Dune will continue to grow and help more developers in 2018.
Jbuilder has evolved from a domain specific industrial tool into a standard build system for the community. There are now 456 packages in opam using Jbuilder from 310 different repositories, and the team has grown with 3 new active developpers.
We are ending this year with exciting work such as cross compilation, with already lots of packages in the
opam-cross-windows repsository successfully using jbuilder to cross compile.
2018 will bring more good news, with in particular the addition of the plugin system which is starting to flesh out nicely. We will also move Dune from the janestreet github organization to a community one.
I thank everyone who contributed to jbuilder by submitting pull requests, reporting issues, participating in design discussions, organizing brainstorming sessions and just using it in their projects. A special thank to @rgrinberg who joined the project early this year and has enormously contributed to it.
27 Likes