)"`
---
### Author:  [@jeremiedimino](https://discuss.ocaml.org/u/jeremiedimino)
#### Post date: [November 14, 2019, 3:28pm UTC](https://discuss.ocaml.org/t/finding-the-root-of-a-dune-project-request-for-comments/4676/9 "2019-11-14T15:28:48Z")
Regarding the original topic, I’m a bit reluctant of making this aspect of dune configurable. I’d rather we settle on the right behaviour. A behaviour that might be less surprising is this one: dune stops at the first `dune-workspace` file. If no such file exist, it stops at the first `dune-project` one.
And that would still make sense regarding the composability aspect of dune. Indeed, the expectation is that each dune project as exactly one `dune-project` file and no `dune-workspace` file. Indeed, `dune-workspace` are meant for setting up workspaces for local development.
---
### Author:  [@Khady](https://discuss.ocaml.org/u/Khady)
#### Post date: [November 15, 2019, 4:28am UTC](https://discuss.ocaml.org/t/finding-the-root-of-a-dune-project-request-for-comments/4676/10 "2019-11-15T04:28:28Z")
If the behavior is changed, wouldn’t it break projects which are nested?
---
### Author:  [@rgrinberg](https://discuss.ocaml.org/u/rgrinberg)
#### Post date: [November 15, 2019, 5:30am UTC](https://discuss.ocaml.org/t/finding-the-root-of-a-dune-project-request-for-comments/4676/11 "2019-11-15T05:30:29Z")
Only if you run build commands in the nested sub projects I believe. In any case, this is simply changing the behavior of how dune infers project roots. For released builds, we don’t rely on inference but on specifying the root explicitly. So it wouldn’t count as breakage anyway.
---
### Author:  [@rgrinberg](https://discuss.ocaml.org/u/rgrinberg)
#### Post date: [November 15, 2019, 5:33am UTC](https://discuss.ocaml.org/t/finding-the-root-of-a-dune-project-request-for-comments/4676/12 "2019-11-15T05:33:13Z")
I’m for this change. I believe it’s consistent with other tools like `git` which also stop climbing up as soon as they find a suitable root marker.
Even without configurability, the old behavior can always be faked with `export DUNE_{WORKSPACE,ROOT}=..`, so I don’t think it’s a big loss to make this non-configurable.
---
### Author:  [@rgrinberg](https://discuss.ocaml.org/u/rgrinberg)
#### Post date: [November 16, 2019, 8:19am UTC](https://discuss.ocaml.org/t/finding-the-root-of-a-dune-project-request-for-comments/4676/13 "2019-11-16T08:19:11Z")
I’ve created a PR that simplifies the root detection: [https://github.com/ocaml/dune/pull/2891](https://github.com/ocaml/dune/pull/2891)
We believe the better behavior is to stop at the first dune-project or dune-workspace encountered. Please let us know if this addresses your problem.
---
### Author:  [@jjb](https://discuss.ocaml.org/u/jjb)
#### Post date: [November 16, 2019, 9:19pm UTC](https://discuss.ocaml.org/t/finding-the-root-of-a-dune-project-request-for-comments/4676/14 "2019-11-16T21:19:02Z")
> [@jeremiedimino](#):
>
> Do you targets start with `_build` ?.
Yes, they are mostly of the form `_build//.exe` or `_build//.install`. I don’t know of a way to select some but not all of the contexts without using such explicit targets, but maybe there is one?
---
### Author:  [@jjb](https://discuss.ocaml.org/u/jjb)
#### Post date: [November 16, 2019, 9:29pm UTC](https://discuss.ocaml.org/t/finding-the-root-of-a-dune-project-request-for-comments/4676/15 "2019-11-16T21:29:20Z")
> [@jeremiedimino](#):
>
> Indeed, the expectation is that each dune project as exactly one `dune-project` file and no `dune-workspace` file. Indeed, `dune-workspace` are meant for setting up workspaces for local development.
I really don’t understand this point. The `dune-workspace` file is AFAIU the only way to specify the opam switches used for the different dune contexts. In order to have even almost reproducible builds, and for all developers of a project to see the same build errors, etc., this information is crucial. That is a very strong pressure to put it (or something that generates it) into source control.
Is there some other expected workflow that can support specifying opam switches to use for build contexts?
(There is an additional step to ensure that the opam switches have the “right” packages installed across developer machines, but that isn’t dune’s problem I think.)
---
### Author:  [@rgrinberg](https://discuss.ocaml.org/u/rgrinberg)
#### Post date: [November 17, 2019, 10:52am UTC](https://discuss.ocaml.org/t/finding-the-root-of-a-dune-project-request-for-comments/4676/16 "2019-11-17T10:52:34Z")
> [@jjb](#):
>
> I really don’t understand this point. The `dune-workspace` file is AFAIU the only way to specify the opam switches used for the different dune contexts. In order to have even almost reproducible builds, and for all developers of a project to see the same build errors, etc., this information is crucial. That is a very strong pressure to put it (or something that generates it) into source control.
I think that reproducibility is the job of the package manager rather than dune’s. What’s required for this is far more than what can be specified in the workspace file anyway. An opam lock is currently one way to provide this information.
Note that there not being checked in was phrased perhaps a bit too strongly here. Dune itself checks in workspace files that make it easy to test against multiple versions. I think the way to understand it is that the dune-workspace file describes the environment (or workspace) rather than the project itself. Hence, it should always be optional as the project should be usable in another workspace. You are of course free to provide configured environments to your users. But today, workspaces aren’t a great solution for that.
---
### Author:  [@jeremiedimino](https://discuss.ocaml.org/u/jeremiedimino)
#### Post date: [November 18, 2019, 8:27am UTC](https://discuss.ocaml.org/t/finding-the-root-of-a-dune-project-request-for-comments/4676/17 "2019-11-18T08:27:01Z")
> I don’t know of a way to select some but not all of the contexts without using such explicit targets, but maybe there is one?
Indeed, there is no way at the moment. That should probably be added though.
Regarding committing the `dune-workspace` file, yh actually that seems fine. It just means that what you are sharing is not just a project but effectively a workspace. As Rudi mentioned, Dune’s workspace files don’t capture very much. In fact, it’s not even guaranteed that the opam switch names will mean the same thing on different machines or that they will be installed already. Some people might also build without opam.
Right now, if you commit a `dune-workspace` file, then anyone who would want to build the project by calling `dune` directly would likely need to install the various switches beforehand.
---
### Author:  [@jeremiedimino](https://discuss.ocaml.org/u/jeremiedimino)
#### Post date: [November 18, 2019, 9:25am UTC](https://discuss.ocaml.org/t/finding-the-root-of-a-dune-project-request-for-comments/4676/18 "2019-11-18T09:25:48Z")
> [@Khady](#):
>
> If the behavior is changed, wouldn’t it break projects which are nested?
To be clear, that’s a breaking change and requires a major version bump. Since we are releasing Dune 2.0.0, we can pass this change now.
---
### Author:  [@grayswandyr](https://discuss.ocaml.org/u/grayswandyr)
#### Post date: [November 18, 2019, 10:12am UTC](https://discuss.ocaml.org/t/finding-the-root-of-a-dune-project-request-for-comments/4676/19 "2019-11-18T10:12:48Z")
I’m in favor of this.
---
### Author:  [@jjb](https://discuss.ocaml.org/u/jjb)
#### Post date: [November 18, 2019, 1:29pm UTC](https://discuss.ocaml.org/t/finding-the-root-of-a-dune-project-request-for-comments/4676/20 "2019-11-18T13:29:05Z")
> I think that reproducibility is the job of the package manager rather than dune’s. What’s required for this is far more than what can be specified in the workspace file anyway. An opam lock is currently one way to provide this information.
I completely agree that the scope of this reaches beyond the responsibilities of dune. But I think it is still important for dune to support an interface to the other components (like opam and a lock file) that are needed for reproducible builds.
> Note that there not being checked in was phrased perhaps a bit too strongly here. Dune itself checks in workspace files that make it easy to test against multiple versions. I think the way to understand it is that the dune-workspace file describes the environment (or workspace) rather than the project itself. Hence, it should always be optional as the project should be usable in another workspace. You are of course free to provide configured environments to your users.
I also agree with this, but each project can only be tested in some limited set of environments, and so “should be usable” is more an aspiration than something that a project can ensure always holds. So I think it is still important to have good support for a project to provide at least one “known good” configuration, which will currently involve some scripting to set up opam switches, lock files, and a dune-workspace file to tell dune to use those opam switches.
> But today, workspaces aren’t a great solution for that.
Maybe, but they are a real help, even if not perfect / covering the whole job.
Note that in this discussion I’m not saying that there is a particular problem, I just want to raise awareness the use case of using dune-workspace files under source control as part of a larger system to provide (close to) reproducible builds, as the discussion seemed to indicate that dune-workspace files were considered to be only a form of user preference file, while they are much more in some case.
[Next page](https://discuss.ocaml.org/t/finding-the-root-of-a-dune-project-request-for-comments/4676.md?page=2)