Delete global cradle files (hie-cabal.yaml, hie-stack.yaml)

[pepeiborra]

I think this is great and I'm happy to merge it, but I have a couple of requests that can either be done in this PR of in follow-ups:

1. Inform the user that there is no cradle haskell/ghcide#788
2. Write the implicit cradle to disk
3. Give the user a choice if there are both stack and cabal project descriptors
4. Delete all the cradle files from ghcide and hls - no longer needed

Originally posted by @pepeiborra in haskell/ghcide#782 (comment)

[fendor]

If we delete them right away, won't users with older versions (HIE/HLS/ghcide) be unable to work on ghcide/hls anymore?

[pepeiborra]

If they are hacking in ghcide HEAD they should be using ghcide HEAD. But there's no rush

[jneira]

Original issue haskell/ghcide#796

[jneira]

maybe the files could be kept as an example of a complex project config?

[pepeiborra]

Can't gen-hie provide such an example?

[jneira]

Well, sort of, but the output is not exactly equal (it generates a path for each module in the exe component f.e.).
You have to install and execute the tool, of course, and you can check the file simply navigating the github repo.

[pepeiborra]

A file called hie.foo.yaml in our repository is a contract - we are telling other devs that this file can be used to load this repo in hls/ghcide. Even more than that, since we are the maintainers, we are telling them that this is the way to load this repo. And now we have made our life harder: we have to make sure to keep this file working and up to date through every change, add tests for it to make sure that it doesn't accidentally break when we upgrade hie-bios or change the layout of our repo, etc...

All that for what? I personally don't use these files anymore since gen-hie became good enough. I don't use stack either, so I am not even able to regenerate the stack hie.yaml file.

To summarise, by keeping them we are endorsing the wrong approach and making our lives harder in more than one way. So no, I don't think keeping them around is a good idea.

[ndmitchell]

Having dedicated examples is fine, even very desirable, but I think HLS should be using best practices, to encourage people to follow. I think we should now recommend not having a hie.yaml in most cases, since its easiest and works well. I've started to delete my hie.yaml files - they force a particular choice (Cabal vs Stack) which different devs make differently, and gen-hie seems to do better than my manual files in most cases.

[jneira]

Fair enough, i suppose implicit-hie is good enough to push explicit hie.yaml to special corner cases

[jneira]

So we should remove them, however, i would like to hear the opinion of the later "maintainers" of those files. We will delete the files if nobody is strongly against.
//cc @Ailrun @beberman @tittoassini @konn

[Ailrun]

So the dev flow will be use gen-hie to generate hie.yaml by dev self?

[jneira]

@Ailrun I think the idea is to use the implicit cradle and only generate the explicit config if you hit some corner case where it does not work
I assume that the implicit cradle works for hls.

[konn]

I think deleting global cradle makes sense, but deleting all cradles is not a good idea.
We need some hie.yaml to make func-test work as expected; for example, for functional test for Splice plugin, importing another module in the testdata required dedicated hie.yaml IIRC.

[Ailrun]

OK then, sounds good for me. (Though I haven't tried implicit cradle for HLS...)

[jneira]

We need some hie.yaml to make func-test work as expected; for example, for functional test for Splice plugin, importing another module in the testdata required dedicated hie.yaml IIRC.

Yeah iiuc this is about the global ones, gonna change the description of the issue to make it clear

[pepeiborra]

One situation where it's unclear whether the implicit cradle works at all is when the hls wrapper is being used to detect the version of ghc before downloading binaries. I think this scenario requires further testing with the implicit cradle

[berberman]

I just tried loading HLS using implicit cradle, and it works smoothly. (though it seems that some components are recompiled repeatedly many times, which would be another issue not related to cradle)

[Ailrun]

It looks like "default" plugins do not work with implicit cradle.
@berberman, Have you tried that too? If you tried, how did you make it work?

[Ailrun]

OK, I have to admit I have agreed to delete global cradles too hastily. It looks like all plugin packages use Cabal cradle, as there is no stack.yaml next to their .cabal files.

[konn]

I have used hie.yaml.stack and global stack.yaml alone just worked; however, it turns out that deleting hie.yaml forces us to use Cabal as a backend, which forces rebuild to me...

[Ailrun]

I think using gen-hie is a way... As @pepeiborra mentioned, it is hard to manage global hie, so instead of managing global hie, let's recommend contributors to manage their own. Maybe we should put that somewhere in the contribution document.

BTW, this still does not solve the problem of "default" plugins, so we maybe need to move them into a package or request implicit-hie to handle such a case.