Please add a flag to prevent stack from re-generating Cabal files with hpack

[peti]

I want my test builds to run with the (hpack-generated) Cabal files that I've checked into the repository; I don't want stack to re-generate them as part of the build. Currently, I achieve that by deleting all package.yaml files before running stack, but it would be nicer if there was a command-line flag or a config option to configure stack's behavior.

[mgsloan]

Why don't you want to regenerate them?

Would it be sufficient to support this in the configuration?

hpack:
  enable: false

[peti]

Why don't you want to regenerate them?

As I said, I want the build to check the Cabal files I have in my repository. Otherwise I cannot be sure that people using them will have a functioning build.

Furthermore, stack breaks the builds by re-generating those files, apparently because the resulting Cabal files are somehow invalid. See https://travis-ci.org/NixOS/cabal2nix/builds/120919872 for an example of a broken build because of that feature.

Would it be sufficient to support this in the configuration?

A configuration file entry would suffice. I would prefer a command line flag, though.

[silky]

that broken build is related to the dash in the cabal project name; that has been fixed recently in this repo but not released yet

sol/hpack#69
#1817

run stack upgrade --git to get a version with that fix in it.

as an aside, the stack build does use the .cabal file in your directory; hpack just makes that file autogenerated.

[peti]

run stack upgrade --git to get a version with that fix in it.

Ah, this is good to know. Thank you for the hint.

The stack build does use the .cabal file in your directory; hpack just makes that file autogenerated.

Yes, I realize that. I appreciate that having Cabal files auto-generated from the hpack inputs can very convenient and is probably a good idea on most occasions. Nonetheless, I really want my travis-ci builds to use the Cabal files that I have committed to my Git repository. I really don't want stack to touch them in any way, because people may clone my repository and build it with cabal-install, thoroughly unaware of the blessings of stack, and then those Cabal files have to work properly.

[silky]

Nonetheless, I really want my travis-ci builds to use the Cabal files that I have committed to my Git repository. I really don't want stack to touch them in any way, because people may clone my repository and build it with cabal-install, thoroughly unaware of the blessings of stack, and then those Cabal files have to work properly.

but what i'm saying is that the cabal files have to be valid already. as you are demonstrating in that link above, the build fails if the cabal file hpack generates isn't valid.

it sounds like you are commiting both the package.yaml and .cabal files.

i actually only commit the package.yaml myself, and count the other one as generated content so don't include it in source control. you could go the other way; and only include the generated .cabal if you wished..?

[peti]

it sounds like you are commiting both the package.yaml and .cabal files.

Yes, that is exactly what I do.

I actually only commit the package.yaml myself, and count the other one as generated content so don't include it in source control.

Yes, that is entirely possible. It doesn't work that way, unfortunately, if you want people to be able to build the code who have neither stack nor hpack installed.

you could go the other way; and only include the generated .cabal if you wished..?

I don't think that makes much sense. The Cabal file is generated frompackage.yaml, so clearly I want to track the source in Git.

[mgsloan]

How about running "git diff" after build and failing if there are differences? Won't work for missing cabal files, but works otherwise

Or, have CI build with cabal install in addition to stack. We do this with stack, for example

[peti]

Dudes, do you intend to add that flag or not?

[mgsloan]

There are many many spots where we could add toggles and knobs, and this will increase the complexity of the code and documentation. We are trying to keep it as simple as possible.

IMHO this is an odd use-case. If you want to ensure that cabal-install works, then test cabal-install.

So, no, I do not intend to add the flag. There are about a hundred things I'd prioritize over adding such a flag. However, I could potentially be tempted to accept a PR. I am not opposed to it, I just don't like adding flags willy nilly for special cases.

[sol]

My input on this:

1. hpack-0.9.0, released 17 February 2015, had a sever bug (see Paths module in generated cabal file breaks Cabal #1814), which was fixed 4 days later in 0.9.1 (thanks to @silky for the patch).

2. The latest version of hpack (that is 0.12.0) only re-generates a cabal file if the previous version was not generated with a newer version of hpack. That is, if your cabal file has a comment on the top that reads

   -- This file has been generated from package.yaml by hpack version 0.12.1.
   

   and you try to re-generate it with hpack-0.12.0, you will get

   foo.cabal was generated with a newer version of hpack, please upgrade and try again.
   

Regarding (1), I now deprecated 0.9.0 on Hackage. The released versions of stack (I just tried generic linux and trusty) still use hpack-0.9.0. @mgsloan can we somehow make sure that stack does not use 0.9.0 anymore. Ideally, it would use the latest version, but at least >= 0.9.1 is crucial.

Regarding (2), I think this is TheRight™ solution to prevent similar havocs in the future.