Support "global" and "local" versions
Created by: AlexeyRaga
Similarly to jenv it would be very helpful to be able to set GHC version on per-project basis:
ghcup set local 8.4.4In jenv case, it would write a local .java-version file and the version that is specified in that file will be used everywhere within that directory.
Activity
Interesting suggestion, but I believe this is exactly what cabal already does!
Check out
cabal new-configure --with-compiler ghc-8.6.4. It will drop the followingcabal.project.localfile:with-compiler: ghc-8.6.4https://www.haskell.org/cabal/users-guide/nix-local-build.html#cfg-field-with-compiler
Created by: AlexeyRaga
Yes,
cabaldoes it! But to useghcin that folder I still need to switch... And the same goes for other tools which would call to globally-available GHC to perform some tasks.Ideally, these tools and scripts should evolve to understand what
cabal.projectsays if it is there, or to go throughcabalmaybe. But, unfortunately, it is not the case yet, and I thought that solving it the same way it is solved for Java or Ruby would be helpful as it would allow the older tools to "just work".Or, if instead of some hypothetical
.ghc-versionwe could usecabal.project/cabal.project.localto "switch" the shell to the specified GHC it would be even better!Yes,
cabaldoes it! But to useghcin that folder I still need to switch...You can use
cabal new-exec ghc. Cabal also writes.ghc.environment.x86_64-linux-8.6.4files.And the same goes for other tools which would call to globally-available GHC to perform some tasks.
Which ones exactly? These might just invoke
cabal --verbose=0 new-exec ghc -- <arguments>instead of plainghc.Having the correct ghc environment for a project is cabals jobs imo. Of course we could do some PATH hacks (as in symlink requested ghc version into
<projectdir>/.bin/ghcand prepend that to PATH in current shell), but that doesn't solve the whole picture and is quite a specific use case.Created by: AlexeyRaga
Well, they could, the problem is that they need to adapt, and they don't for various reasons.
One example would be HIE. The
cabal new-*support there is coming slowly because it doesn't seem to be as simple as just invoking everything throughcabal. Socabal new-*is currently supported sans some edge cases, the compiler version in the project file is one of them. HIE usesghc-modinternally, and I am not sure ifghc-modis the source of it, but if it is then moreghc-modbased tools are affected...Having the correct ghc environment for a project is cabals jobs imo.
Sure, but since we know how to
setglobal GHC, wouldn't it be nice/helpful to be consistent and to be able to say that when you are in a project, the whole environment respects the project settings?If I am not mistaken, you can configure
mavento use the specificJavaversion, and we can say that it is it's job to do so. Butjenvis still very useful because it allows the selected version to be shared between different tools,mavenincluded.I think the better way is to fix the tooling. And until that time use a local workaround/hack (not that difficult to script I would say).
There are two reasons I'm currently questioning this feature to be part of ghcup:
- it is a temporary workaround... are temporary workarounds something we want as ghcup features?
- I don't see how to implement this cleanly without PATH hacks. Currently ghcup only requires very minimal change to the users PATH and doesn't further mess with PATH. It then just uses symlinks to manage these. How would you implement this?
Created by: dwijnand
The way
jenvimplements this is also with just a minimal change toPATH(export PATH="$HOME/.jenv/bin:$PATH") but the executables there aren't just symlinks to the selected global version executables, but rather they're bash scripts that take into account.java-version(as well asJENV_VERSION, as an over-override).Created by: dwijnand
Yeah.
jenvcalls them shims and generates them with a script: https://github.com/jenv/jenv/blob/e253e3654e624f0161aed21745a4e1a796d554b2/libexec/jenv-rehash.That's a big commitment for a corner use case, isn't it? Especially since you can just remember to
ghcup set <ver>before working on a different project. You can write bash functions/aliases for that to make it more convenient.I mean, how often do you switch between projects that this actually is a problem?
Created by: dwijnand
Speaking only for myself, as a maintainer and contributor to a large number of projects, often (for example) projects are in different states of Java 6/Java 8/Java 11 support and/or commitment so having repo-committed and platform/arch-agnostic metadata like
.java-versionis very convenient.But I'm only presenting the use case for what it represents and how it helps for Java projects. For Haskell, seeing as I'm just learning Haskell now, so far I've been fine with a single, latest Haskell set up.
Created by: AlexeyRaga
I mean, how often do you switch between projects that this actually is a problem?
Often, infrequently... We have many projects/services, and sometimes I even need to work with more than one at once (i.e. I have >1 project opened in my editor(s)).
But I didn't expect that this feature would be somehow undesirable. I thought that having a consistent working environment within a project folder would be nice to have (and also useful). I think it would make project GHC set up reliably once and for all without saying that everything around must adapt and that we should wait for when it happens.
Are there disadvantages of having it this way that I don't see? Reasons for which we should not do it?
I also understand that it could be impossible to implement due to some technical details...
@hvr had serious concerns that this may break assumptions of cabal, can you elaborate?
