Add raw-project stanza

[phadej]

@RyanGlScott can you test whether this works for you. I'll ping you again after ICFP deadline ;)

[RyanGlScott]

Thanks, @phadej! I'll try this out when I get some spare cycles.

What is the relationship between this PR and #129?

[phadej]

@RyanGlScott there is --local-ghc-options already. --local-ghc-options infers package names and makes

package haskell-ci
  ghc-options: -Werror

as you can see in https://github.com/haskell-CI/haskell-ci/blob/master/.travis.yml#L101-L102

[phadej]

@RyanGlScott I can add raw-local-package too, if it will make life easier, .e.g if library-coverage is something you want to specify for all local packages (and it doesn't work in the same way ghc-options doesn't work) (it will exclude source-repos by design).

[phadej]

According to https://cabal.readthedocs.io/en/latest/nix-local-build.html#cfg-field-coverage coverage should work top-level (and will apply only to local packages). So looks like --ghc-options is the only field we need to hack around.

[RyanGlScott]

I'm not sure exactly what the intended semantics of raw-local-package are. But my use case is that I currently have this cabal.project checked in to the primitive repo:

packages: .
          ./test
          ./bench
package primitive
  ghc-options: -Wall
package primitive-tests
  ghc-options: -Wall
package primitive-benchmarks
  ghc-options: -Wall
package quickcheck-classes
  flags: -aeson -semigroupoids -semirings

Moreover, I have to laboriously copy the contents of this file over to .travis.yml. Note that there's more than just ghc-options specified here, which leads me to the conclusion that having haskell-ci read the contents of this file would be the cleanest solution.

Not having this feature isn't a show-stopper by any means, since I could just as well copy over the contents of the cabal.project file over to a raw-project stanza in cabal.haskell-ci. But that also requires some duplication, and it would be convenient if haskell-ci could just automate this process instead.

[phadej]

First, --local-ghc-options is a workaround of haskell/cabal#3579. When it get fixed you can simplify

package primitive
  ghc-options: -Wall
package primitive-tests
  ghc-options: -Wall
package primitive-benchmarks
  ghc-options: -Wall

to

ghc-options: -Wall

And then copying over isn't so big.

---

Secondly, locally I would not do

package quickcheck-classes
  flags: -aeson -semigroupoids -semirings

but only set them on Travis. Locally, you get more sharing benefit from global store if you go with default manual flag values (and for sure you have aeson and semigroupoids built!)

[phadej]

I'm trying to think, what could go wrong if one just copies over cabal.project, modifying packages field.

[RyanGlScott]

I'm trying to think, what could go wrong if one just copies over cabal.project, modifying packages field.

The only downside that I can think of is that you might only want a subset of the options from a cabal.project file to be enabled on CI. For instance, there are some packages (such as X11) that simply can't be installed in a CLI-only environment like Travis, so it probably wouldn't make sense to copy over flags: +x11-support if that would imply building X11. I'm not really sure of a good design for allowing this level of granularity, however.

[phadej]

@RyanGlScott you can however turn off the flag after, with raw-project, so it's not a biggie. Especially in your X11 example you are sure you want to turn it off, not only reset to default.

EDIT: also Travis has some headless-X11 stuff, so you might even succeed, if you try hard enough.

[RyanGlScott]

Ah, I hadn't thought of that. Are you saying that it you had this in your cabal.project file:

package blah
  flags: +x11-support

And this in your cabal.haskell-ci file:

raw-project
  package blah
    flags: -x11-support

Then the -x11-support in cabal.haskell-ci would take precedence over the +x11-support in cabal.project?

[phadej]

Yes, I'd append the raw-project contents. I don't see why you would like to prepend them (to be overriden by cabal.project, what's the point?)

[RyanGlScott]

OK! In that case, I really can't envision any downsides to this idea. I'm not sure whether we'd want to copy over the cabal.project contents as the default behavior or not, but either way we could introduce the ability to toggle this behavior with a flag.

[phadej]

@RyanGlScott I merged, this but please comment after you had chance to try out

[RyanGlScott]

@RyanGlScott I merged, this but please comment after you had chance to try out

Sorry for the delay! I've finally had a chance to try this out, and it works beautifully. I was able to remove a large number of hacks I have to apply on top on haskell-ci, so now I've down to only a handful of things I have to hack around. Only #182 and #236 stand in the way of deleting this TravisYmlHacks module entirely :)