Suggestion: deprecate the global default package environment file

1

Every now and then, my colleagues run into problems with scripts which invoke ghc directly getting confused because they happen to have a global package environment file at $XDG_DATA_HOME/ghc/arch-os-version/environments/default (whereas most people at my work don’t have one of these). I recently learned that ghc reads this file by default if it exists, which seems to just mess things up if you’re in any kind of cabal project, or just generally if you’re not expecting ghc to use this global configuration. Right now, it seems like you have to remember to pass -hide-all-packages or -package-env=- pretty much whenever you’re invoking ghc directly, which is a bit inconvenient.

The global package environment file is clearly not well-loved by the community either; see, eg:

Is it feasible to just do away with the global default package environment? I’m imagining changing ghc so that it would stop reading that file by default if it exists, and that you could still opt in to having ghc read that file by passing -package-env default or by setting GHC_ENVIRONMENT=default.

My guess would be that most recent-ish haskell tutorials don’t rely on this behaviour (especially since this behaviour is now opt-in via cabal’s --lib flag) and it wouldn’t be particularly difficult to work around in the places that do?

3 Likes
2

Can’t you just do this in the scripts?

I also think that cabal install --lib is probably the only way newcomers are writing to the global environment file. (That has some quite strong warnings on it nowadays, so I’d be interested to hear how your colleagues came up with the idea to use that.) So I’d rather see further limitations of that instead of changing ghc’s behavior. For example we could say --lib is only allowed if you also provide --package-env. You could still say --package-env=default, but perhaps that would already raise the threshold a bit and also at least give people some hint of what they’re actually doing.

3 Likes
3

Can’t you just do this in the scripts?

Yes - that is what I have done. It works, but it feels to me like not reading this global package environment would be a better default.

4

Well, that would also be a breaking change.

Related issues:

I personally think for something like cabal install --lib, which is by nature an imperative command, the default should indeed be to install globally. That’s what 98% of the package managers do and what users are generally used to.

The problem is that cabal’s UX is now a hot mess, with some semi-declarative interface that doesn’t actually go all the way. And now people mix both of those paradigms and cabal isn’t very good at separating those. This is what sandboxes were good at: imperative, but local.

1 Like