maralorn

I am confused. That idea sounds to good to be true. Also I don‘t think any other auto generated part of nixpkgs does this? There have to be reasons why...

I am quite out of my depth here. And there might well be a correct solution to this problem. But maybe you can just move the files in the postinstall...

Thanks @teto. Sadly a majority of maintainers of this project thinks that flakes is an experimental feature and endorsing its use is a footgun for beginners. Imo we can keep...

On further inspection: @teto where did you get the flake template from? It seems riddled with design decisions that seem very opinionated and overcomplicated. Templates like these are a reason...

@stianlagstad That package has no explicit export list so everything in it should be exported. Also it’s listed as an exported module. Have you inserted an `import Distribution.Hackage.DB.Errors` in your...

@m4dc4p You mean this affects packages which have only executables and internal libraries? Note that you can currently work around this by applying the function `haskell.lib.justStaticExecutables` to the resulting packages.

I think we should strive at being very clear cut here. For every kind of override we do we should decide whether to do it in cabal2nix or in nixpkgs....

This might still be a good idea, but just fyi: You can pass `lua-arbitrary = null;` to the function to circumvent the problem.

@emptyflask I can confirm that it stopped working for me somewhat around the same time. :-(

Apparently this is caused by a wrong load order of plugins. This plugin has to be before the nvim-runtime in the runtime-path. The first syntax file wins. @emptyflask This broke...