Renaming to Dune

[ghost]

This is the first step in renaming Jbuilder to Dune.

This PR implements the minimum required from #461 to do the switch: it adds support for dune-project files. The current version of the dune language is 0.1 and is exactly the same as jbuilder. This means that to convert a project to dune, one just needs to add a dune-project file with:

(lang dune 0.1)

as we implement the other features of #461, we will increase this version number.

This PR builds and installs both dune and jbuilder binaries. The only difference between the two is the doc and the fact that dune no longer looks for jbuild-workspace* files.

[ghost]

Ok, there are still a few things to do, but I think this PR is big enough already. What it does is the following:

• Rename the package to dune
• Rename the libraries from jbuilder.X to dune.X
• Build and install two binaries: dune and jbuilder
• Build and install two sets of man pages
• Add support for dune-project files

The two commands behaves exactly in the same way, except that jbuilder looks for jbuild-workspace file and dune looks for dune-workspace files to find the root of the workspace. Additionally dune ignores files prefixed with dune-workspace, while jbuilder still treat files prefixed with jbuild-workspace as root markers. Both commands accepts dune-project files, in order to keep the code simpler.

dune-project files as used as root markers when no dune-workspace file is found. Additionally they are used to mark the root of scopes. So currently we have two ways of defining a scope:

• by having at least one <package>.opam file in a directory
• by having a dune-project file

Having both is acceptable as well. In a distant future, the first way will go away and it will be required to have a dune-project file.

What is missing in this PR and will be done in separate PRs:

• update the manual
• accept dune files in addition to jbuild files, so that users can start renaming their jbuild files
• add support for dune-fs files

[ghost]

I'm not sure what is the best way to fix the CI BTW, given that the script uses opam and that many packages rely on the package name being jbuilder. @rgrinberg @dra27 any idea?

[rgrinberg]

Is it possible to leave the old jbuilder.opam file and just make it depend on dune? We might need to make a first release with the dune package to make this work however.

[ghost]

I'll try that

[rauanmayemir]

Pardon my nitpicking, but are you dead set on using dune-project as filename? Even if it's only one 'dune-project' file per project, one 'dune-workspace', and one 'dune-ignore' - those dashes are somewhat pain to deal with in terminal.

I wonder if it would be possible to solve this with same dune file in the top level and project stanza. Dunefile would look cool, too. 🙈

(OTOH, same dune name for both command and config filename might turn out to be inconvenient)

[ghost]

Now is indeed a good time to raise such questions :)

There is no strong technical reason to have separate files. However, when you create a workspace composed of several projects, dune-project files are used to partition the source tree into independent parts. This partitioning is used to limit the visibility of private libraries, to allow using different versions of the specification in different parts, etc... Somehow it feels more natural if this partitioning is clear by just looking at the files, without looking at their contents.

For jbuild-ignore, the plan is to replace them by dune-fs files. I suppose we could merge them into dune files directly, to remove one configuration file.

Regarding dune-workspace, these shouldn't be committed in repositories, they are only for local development.

In practice, one should only have one dune-project file at the root of their project.

those dashes are somewhat pain to deal with in terminal.

What do you mean by that? dashes are easy to type in all terminals, I believe that's why command line arguments starts with dashes.

[rauanmayemir]

Understood the reasoning for special project files.

For multi-project setups:

1. Do we need to have a separate dune-fs file per project?
2. Will dune-fs have responsibilities other than ignoring dirs?

Somehow it feels more natural if this partitioning is clear by just looking at the files, without looking at their contents.

On this, I agree. Having separate non-project related config files also makes it more flexible to build workflows on top of dune (e.g with esy).

What do you mean by that? dashes are easy to type in all terminals, I believe that's why command line arguments starts with dashes.

I misspoke. What I meant is the autocomplete nuisance when you have multiple similarly prefixed filenames and you want, for example, to quickly nano dun[press tab] in terminal. Ignoring the actual naming, something like this might be more convenient:

% root
.duneignore
Duneproject
dune-workspace

[ghost]

1. Do we need to have a separate dune-fs file per project?
2. Will dune-fs have responsibilities other than ignoring dirs?

A project might have, 0, 1, or more dune-fs files. They are described in #461, in the section dune-fs files. They are mostly just for ignoring files and directories, however they is a small difference between things that are completely ignored and things that are "raw data". Since they describe how dune should interpret the file system, it feels like they should be separate as well. They basically come before the rest. Using a dot file seems good though.

I misspoke. What I meant is the autocomplete nuisance when you have multiple similarly prefixed filenames and you want, for example, to quickly nano dun[press tab] in terminal. Ignoring the actual naming, something like this might be more convenient:

Ok, that makes sense. I find this annoying as well for program names. In general, I would expect that dune-workspace files are written outside of the project in a parent directory. If dune-fs files start with a dot, that leaves us with only one dune-project files. There might also be one dune file, however most projects put their sources in sub-directories, so it's likely the only file needed at the root will be a dune-project file. At which point we don't have the completion problem anymore.

Regarding the naming, Duneproject/dune-project/... and dune/Dunefile/.... I tend to find capital letters annoying for filenames. I also thinks that it's good to follow a naming convention for the various files. That's why I proposed this naming. But until the next release, these names are still open to discussion.

In light of this discussion, my current proposal is the following:

• dune-workspace for worpskace files
• dune-project for project files
• dune for describing libraries, executables, etc...
• .dune-fs for FS description files

[rauanmayemir]

Sounds great!

[ghost]

@rgrinberg tests are passing in Travis now. This PR is ready for review :)

[ghost]

BTW, I simplified this PR a bit. Thinking about it, it's going to be painful to have to maintain several binaries with distinct behaviors. Plus it's going to make it harder for users to switch.

So instead the two commands dune and jbuilder are now exactly the same. This means that they both recognize the old and new files. To move away from files such as jbuild-workspace, we can proceed as follow with a few releases between each step:

• accept them just as before
• accept them but display a waninng
• ignore them and display a warning
• ignore them entirely

[rgrinberg]

Looks good. Why not rename jbuild to dune for the project too?

[ghost]

There is no support for dune files yet, but once there is we should do it indeed

[rgrinberg]

Hmm, I think we should support for such files before the release. Otherwise this adds unnecessary confusion to users who would expect that dune is valid wherever jbuild is.

[ghost]

Indeed, I was planning to do it in this PR originally but it was becoming too big. I think the following needs to be done before the release as well:

• update the manual to talk about dune rather than jbuilder
• add support for .dune-fs files (so that users can convert all their jbuild* files at once)