Consider a different name for the hie.yaml file

[ndmitchell]

The current hie.yaml is an abbreviation for Haskell IDE Engine. That's meaningless to most people, and no longer represents the IDE we recommend. A name like haskell-ide.yaml would make it clearer to users who encounter a file what that file was doing.

I don't imagine migration will be too hard - we can search for both filenames.

[fendor]

I don't feel strongly about this. I am fine with either.

[ndmitchell]

Would be good to get some other opinions, e.g. @pepeiborra @alanz

[alanz]

I am happy with this idea.

[pepeiborra]

+1 This is a great idea

[jneira]

i like short names if possible, and it seems to me that haskell ide engine is generic enough to survive the outdated impl.
But I am not strongly against so if you like it, go ahead.

[michaelpj]

A name like haskell-ide.yaml would make it clearer to users who encounter a file what that file was doing.

That suggests to me that it configures the "whole IDE". But it doesn't - it configures specifically the part where it figures out how to build my project. If, say, we added some unrelated persistent settings for HLS (that weren't covered by LSP configuration), then where would we put them? Certainly we can't put them in the file hie-bios reads, so it would have to go somewhere else. So it's more like haskell-project-build-info.yaml.

Perhaps HLS should have haskell-language-server.yaml, which contains a sub-stanza that it could pass to hie-bios directly when it invokes it, rather than hie-bios having a separate configuration file. Then we really could have a config file for "everything HLS".

[ndmitchell]

Perhaps HLS should have haskell-language-server.yaml, which contains a sub-stanza that it could pass to hie-bios directly

I like that. It also seems more reasonable for HLS to know where configuration files etc live, rather than hie-bios to go hunting around. E.g. HLS might decide not to descend up past the current workspace directory.

[Avi-D-coder]

Perhaps HLS should have haskell-language-server.yaml, which contains a sub-stanza that it could pass to hie-bios directly

I would very much like to avoid this. If cradle info is mixed in with other configs, gen-hie will have to only modify the relevant section, and try to respect formatting. A separate hie-bios config file (whatever it's called), makes my life much simpler.

[jneira]

Another argument to not move the config is imho that config will (and should) be removed, when the build tools give enough info to hie-bios to not make users duplicate the build info in two config files (.cabal and hie.yaml/whatever other config file).