cabal init -w/--with-compiler pins GHC version in cabal.project

[m-renaud]

PR #5658 added support for initializing a cabal project with a specific compiler, but does not pin it anywhere, you still need to run cabal v2-configure -w compiler-v.e.r so that other commands use the same version (and this only adds it to cabal.project.local which isn't checked into version control systems).

Related issues: #5661

[andreabedini]

Commenting since I was just surprised by the fact that cabal init -w ghc-9.2 didn't pin ghc-9.2 anywhere.

[Mikolaj]

But, in that case, should cabal init pin the compiler that happens to be in the path? Because, in all other commands, -w has the same effect as changing the compiler you have on your path IIRC. Also, I think the only way to pin the compiler is to add bounds on the base package, which would require adding and maintaining a table of GHC vs base package version.

[andreabedini]

I would not expect cabal init to pin anything but I would expect cabal init -w blah to write with-compiler: blah in cabal.project.

[Mikolaj]

And does cabal init, so far, ever create cabal.project?

I see that we I do cabal init --emal=foo, it doesn't ask me for email (in the default interactive mode), but otherwise it does. Should cabal init ask for the compiler if no -w is given? Any precedent for options that don't correspond to interactive prompt? If not, do we want such a singular behaviour? Any candidates to treat so as well?

[andreabedini]

@Mikolaj all good questions, here is what I think.

And does cabal init, so far, ever create cabal.project?

I don't know. My assumption is that as cabal as gained ability to deal with projects, cabal init should follow.

Should cabal init ask for the compiler if no -w is given?

I didn't think of interactive mode. Do prompts have a default? The question could be "do you want to use a speicfic version of ghc", default is no and that doesn't add a with-compiler line.

[Mikolaj]

OK, it seems the problems I invented may have solutions. @ptkato, as the world expect on cabal init, would you like to comment? @emilypi, as the designer of recent iterations of cabal init, would you share your thoughts? Anybody else?

[emilypi]

And does cabal init, so far, ever create cabal.project?

It does not. However, we're talking about different flags with intersecting names, that have different purposes:

• -w as it pertains to build compiles with a particular GHC version in PATH, or what's in the cabal.project file.
• -w as it pertains to configure writes a project build option to cabal.project.
• -w as it pertains to init uses the information to specify base.

If we support writing to cabal.project from init, we are now inviting people to mix concerns: generating a cabal file (a project specification) is not the same as generating a cabal.project file (project build options). Munging concerns implies a new set of problems: what subset of cabal.project options do we want? Should we allow users to set constraints as well? Use flags? I would argue that supporting anything not pertaining to project specification, even a subset of cabal.project options, is incorrect.

[gbaz]

My view is cabal init should not generate a cabal.project file.

We do already have a way to generate a cabal.project.local file. It is called cabal configure.

And we have a perfectly good meaning to passing with-compiler to cabal init -- it allows cabal init to work, as it requires (or at least used to, at the time that support for -w was added) a ghc in scope to operate.

Everything at the moment appears to Work As Intended to me, and I propose closing this issue.

[emilypi]

I support closing the issue as well.

[Mikolaj]

• -w as it pertains to configure writes a project build option to cabal.project.

That's probably cabal.project.local? I tried to find an option for cabal configure to write to cabal.project, but I couldn't find one. However, it's presumably not a big to deal to copy the file manually.

I think I support the separation of concerns stance, even if the separation was just regarding files that are modified. Perhaps we could hint users that they can use cabal init for the project spec and cabal configure for build options and explain the distinction a little bit, e.g., link to manual chapters about spec and about build options?

---

Unrelated, commandline docs for cabal configure say

Examples:
  cabal configure --with-compiler ghc-7.10.3
    Adjust the project configuration to use the given compiler
    program and check the resulting configuration works.
  cabal configure
    Reset the local configuration to empty and check the overall
    project configuration works.

but the "check the resulting configuration works" is probably not true any more?

[jneira]

Agree about not touching cabal-project, but a very least we should improve docs about, including the interesting dissection:

It does not. However, we're talking about different flags with intersecting names, that have different purposes:
-w as it pertains to build compiles with a particular GHC version in PATH, or what's in the cabal.project file.
-w as it pertains to configure writes a project build option to cabal.project.
-w as it pertains to init uses the information to specify base.

cause when a thing with the same "key" has so different purposes which can be still applicable somehow to other commands, it confuses users

From cabal help init

 -w, --with-compiler=PATH       give the path to a particular compiler

That is exactly the same info than -w for cabal help build
Imo it should tell us: give the path to a particular compiler to specify the base version
Or use another argument name instead -w/--with-compiler

[emilypi]

I agree with @jneira here, and @Mikolaj it sounds like we have 2 tickets in particular that should be opened in favor of closing this issue:

1. Fix the configure docs
2. Expand the init docs to explain what -w means in that context.

My instinct tells me this is a problem with bettering our communication, not something we need to make code changes about.

[Mikolaj]

@emilypi: agreed. Volunteers to open tickets?

@m-renaud, @andreabedini: is it the same for you, in your use case, whether you have with-compiler: blah set in cabal.project or base >= bar in baz.cabal? Because we seem to agree the latter has a place in cabal init, as @jneira describes ("give the path to a particular compiler to specify the base version"), even though it's probably a bigger coding and maintenance effort (unless we already have the GHC vs base table somewhere in the vastness of the codebase)? If so, we could leave this ticket open changing the title from cabal.project to baz.cabal.

If it's not the same, I think cabal configure could be used to set with-compiler: blah in cabal.project.local and then the user can copy over to cabal.project. This is already implemented, so we could close this ticket if you don't object.

Let me copy a possible long term perspective on that from #hackage:

• as a policy, i think going for "simple, atomic commands that don't munge multiple things into the same concept" is best going forward re: issues like 5700.
  nit should generate a spec for *.cabal. configure should generate fixed build options in cabal.project. build should use both, preferring cabal.project's options.
• that's definitely a sound principle for plumbing; however, that does not preclude porcelain 3-in-1 commands that let the user do all that needs to be done, e.g., when creating a new project, with one command
  whether cabal init is plumbing or porcelain was not clear to me, but I'm fine assuming it's plumbing, even though it's interactive by default
  if we have the resources at some point to build a 3-in-1 command that calls init, configure and something else and does it all, we can make cabal init not interactive by default and the overreaching 3-in-1 command interactive and it will be even more clear what is what

[andreabedini]

I had totally missed that init -w would change the bounds of base (as noted, it's not written in the help). (see edit below)

My original comment came after discussing with colleagues about the difference in workflow between stack and cabal. A stack user noticed that with stack you never have to worry about the ghc version, since it's fixed at the start of the project by the choosen snapshot. As I was explaining my workflow to my colleage (ghcup + cabal configure/build -w), I noticed I could pass -w to cabal init and that would have been equivalent to the stack workflow.
Apparently this is not how init -w works and I was mistaken.

Now, fixing the base version doesn't help this endeavour since it only tells cabal which ghc version not to use. What I would like to have, is a version of configure -w at project initialisation.

edit hold on, on a second reading, is this a current feature or a proposed one? if it's only being proposed now I am strongly against it: why with-compiler specifies the bounds on base? perhaps with-base would be the appropriate name, I would expect with-compiler to specify ... the compiler :)

[jneira]

perhaps with-base would be the appropriate name, I would expect with-compiler to specify ... the compiler :)

I was about to propose that alternative in my previous comment, and after take a look to flags handling and see -w is shared with build maybe it is more convenient

[emilypi]

Not going to change a flag name without trying communication first. Keep in mind that tooling depends on stable apis and this would break it. If we're just going to end up bikeshedding the flag name, we should at least do the following:

1. Change the docs to reflect the intent in all 3 cases
2. Propose the change publicly on a bunch of different venues
3. Merge the change for a major version a year out (perhaps 3.12)
4. ???????
5. Profit (aka let the complaints roll in, and tap the sign endlessly until they stop complaining)

But my position is a strong "no" on bikeshedding flag names unless the actual result is a serious conflict between the flag's intent, usage, and documentation. Keep in mind - we don't need to reinvent the wheel. We need to bring Cabal up to a reasonable engineering standard, which means good communication, code hygiene, and stability.

[andreabedini]

@emilypi I have no intention of breaking stuff.

IMHO --with-compiler=PATH having different meaning in the three cases is bad engineering and bad user exerience, whether or not the three meanings are properly documented.

I don't even care about this flag at all. All I was doing is investigating if cabal supports specifying a compiler to use when creating a project. It does not. End of the story, and end of this ticket. There is no bug, cabal is working as intended.

If anybody feels like discussing the use case I was interested we can do it in a new issue.

[Mikolaj]

I've opened issues #8102 and #8103.

Thank you everybody for the conversation. Even just sharing user experience in a thoughtful form and discussing it is priceless and keeps development grounded.