Finding the root of a Dune project (request for comments)

Ecosystem
21

Agreed. I guess this configuration is basically what one should use to work on the project iself, right?

22

Agreed. I guess this configuration is basically what one should use to work on the project iself, right?

Yes, exactly. It also serves as a good point of reference to debug failing builds in other contexts, which can be extremely helpful.

23

I have been wondering about putting such information in the dune-project file. For instance, we could start by by precising which version of the compiler one should use to work on the project, and if the compiler is more recent, then there is no point showing deprecation warnings.

1 Like
24

I think that this information fits better in workspace files. I like the fact that we have the following distinction between dune-project and dune-workspace files:

  • There’s only one dune-project and its always active
  • There is zero or more possible workspace files but only one is active at a time.

I think information such as which version of OCaml should be used falls into the second category. For example, some projects may need to support multiple versions of the compiler. This can be made to work in project files, but in workspace files it’s already natural to add this. Another point is that it can be useful to have one source of this information form multiple dune projects being developed simultaneously. I think it would be quite annoying to repeat this information everywhere.

Currently, the information that we store in the dune-project is always “published” and it does not vary after that. I don’t think we should extend it with environment/user specific configuration.

25

Looks like you have some good ideas about how to extend workspace files to aid reproducibility. I’m definitely in favor of extending workspaces in this direction, but I still don’t know what are the concrete problems you have that are not addressed by the current set of tools. In particular, we now have 3 competing ways of working with reproducible dune projects:

  1. opam in conjunction with local switches and lock files
  2. esy sandboxes and esy locks
  3. the duniverse tool. Which is only a solution for dune only projects, so we can ignore it if this restriction doesn’t fit you.

Sounds like you’ve at least tried the first approach. Could you comment on where it’s not working? From there we can discuss how to extend workspaces to accommodate those needs. Have you tried the 2nd or 3rd approaches? They have their own advantages that might solve the problems you’re having.

Before extending workspaces, I’d like to make sure that we have at least a somewhat coherent picture of the feature should look like - with an eye towards supporting users from all three camps.

PS: it seems like we’ve hijacked this thread for something that isn’t related to the original topic. Perhaps we should start a new thread?

26

Update: looks like there’s more controversy around this change than I expected. It’s not going to make it to dune 2.0