Automatically create opam switch in `dune init`

[NicholasLYang]

Desired Behavior

Add a flag to automatically create an opam switch when initializing a new dune project. Eventually, this could be the default behavior for dune init.

That way, users fall into the pit of success by isolating their dependencies. Otherwise, they run the risk of relying on implicit global dependencies, or breaking other projects when they change dependencies in their current project.

Example

dune init executable my-app --with-switch

Will initialize my-app with a local switch for that folder. Flag name is of course up for debate.

[maiste]

Hi, thanks for the request! 😄

Add a flag to automatically create an opam switch when initializing a new dune project

I understand the reason behind it. However, I see a problem in letting dune creating the opam switch as users would still need to eval the opam environment (unless they add the opam hook). The result is they can still mix global and local dependencies. Note, I don't have a strong opposition to include it in dune init but I'm unsure of the effect.

I'd like to have another Dune maintainer point of view on this.

Eventually, this could be the default behavior for dune init

I disagree with it: dune init should be able to run either with opam global, opam local or with dune pkg. The three workflows are supported right now, and the current default makes it possible for users to decide the one they want.

[NicholasLYang]

Could we print out a suggestion on init to eval the opam environment/add the hook? I think as long as it's advised, it's still an improvement.

As for default behavior, perhaps we can revisit this if/when the feature is implemented and people are using it. In my experience, local by default dependencies have been a marked improvement to developer experience in the JS, Rust, Ruby, and Python ecosystems, but of course I'll defer to people with more OCaml experience 😄

[maiste]

Indeed, people can be asked to do the eval. The switch should either be empty or take a compiler as parameters to give users the possibility to choose. As I said, I don't have a strong opinion against adding this, but I would get other maintainers point of views 😄

I hear your point, and I myself prefer using the local switch. However, the local switch cost a lot of space because it installs the compiler every time. It can be time-consuming because the compiler is compiled for every switch (per project in this case). Hence, some people prefer to use a global switch to avoid these problems. As the two workflows (and package management is slowly raising as we push for it) are common, I would recommend keeping the default agnostic as it is today.

[Leonidas-from-XIV]

Given the dune pkg usecase keeps getting more and more feasible, I really don't think that creating functionality to create a local opam switch at this point is reasonable. Possibly a few years ago.

It also addresses the "local as default" concern, which I agree is most likely the best solution. Global shared switches are basically just a crutch because local switches are expensive but that is no longer that much the case with dune pkg.

[NicholasLYang]

Agreed! Will close if there's no other objections