Allow paths as environment file names

[fgaz]

Mirroring the behaviour of ghc and cabal install --lib

"foo" -> $ghcEnvDir/foo
"./" -> $pwd/.ghc.environment.$ghcPlarform-$ghcVersion
"./foo" where foo is not a directory -> $pwd/foo

Closes #17

[fgaz]

this is how we check for path-likeness in cabal, but I'm not sure it's the best way to do it

[phadej]

Yes, I don't like this either. I think picking some format (e.g. alphanumeric + -_) to be environment names, and everything else interpreted as paths would be better.

I'm not sure. I'll think some more and do the changes myself. Bear with me.

[fgaz]

Is there anything I can do to help with this?

[fgaz]

ping :)

[fgaz]

Ping :)

I also think it could be a good idea to make . the default environment, maybe with a --default/--global flag that is sugar for --name=default

[phadej]

I also think it could be a good idea to make . the default environment,

I disagree.

[fgaz]

Why? I found myself using local environments more often than global ones. There is a risk of littering the filesystem with them though...

[phadej]

Why?

There is a reason why I made this tool outside of cabal-install to begin with: I can tweak it to my liking. I'm happy with how cabal-env works now. We can discuss about adding a config file, but the defaults is up to me to decide.

[fgaz]

the defaults is up to me to decide

Sure, just wanted to know the reason since that'd apply to a cabal command too. Personal preference is valid of course!

[jneira]

I also think it could be a good idea to make . the default environment, maybe with a --default/--global flag that is sugar for --name=default

But it has the risk of break the local project build if cabal env is executed in a stack/cabal project root dir.
I would force the definitive solution to be a named environment by default (with flags to switch to global/local), although it has the incovenient of passing the name to ghc(i). I guess you could put the name in the ghci start config file.

[fgaz]

But it has the risk of break the local project build if cabal env is executed in a stack/cabal project root dir.

Build tools that provide their own environment/packagedb to ghc are supposed to override it though. In fact, I don't think environment files can break cabal builds. If stack does not reset the environment, i think that's a bug in stack since there could always be an user-generated one in the way.

I think the biggest issue is having hidden state in your filesystem.

Anyway I think this discussion should go in haskell/cabal#6481, since @phadej already decided for cabal-env

edit: okay... I didn't expect it but GHC_ENVIRONMENT=not-existing cabal build fails... maybe that should be fixed in cabal