Skip to content

Haskell: Fail on warnings #250

Closed
wants to merge 1 commit into from
@sol
sol commented Jun 15, 2014

No description provided.

@joshk
Travis CI member
joshk commented Jun 15, 2014

Can you explain a little more why this change is good.

@sol
sol commented Jun 15, 2014

@joshk Personally, I don not want warnings in my code and hence want CI to fail on warnings. But we should wait a little bit before merging this, to give others the chance to voice there opinion.

https://twitter.com/solirc_/status/478077224185118720

I used to just have -Werror in my cabal file, but with cabal repl this becomes impractical, as during development you do not want to fail on warnings.

@ip1981
ip1981 commented Jun 15, 2014

+1

@dmalikov

-Wall

@sol
sol commented Jun 15, 2014

@dmalikov Also I agree, and I want it like that for my own code. Some people consider certain warnings as useless. So I think which warnings to enable is best left to the package author.

@chrisdone

If warnings were meant to break compile they would be errors. -1

@sol
sol commented Jun 18, 2014

@chrisdone I agree with you (except for the -1), I still think this change is the right thing to do.

I make a difference between a CI job and e.g. installing a package from Hackage. If I install a package from Hackage, I always want it to succeed, regardless of warnings. On the other hand, if I as a package author enable a certain set of warnings I did that for a reason and I want CI to fail in that cases so that I'm notified about it and can fix it (that can either mean ignoring the warnings or changing the code).

Indeed, the motivation of this change is to keep -Werror out of cabal files, so that warnings do not break compile.

@feuerbach

-1 since this violates the principle of least surprise. If the user didn't specify -Werror in either foo.cabal or .travis.yml, s/he wouldn't expect it to be turned on.

@ip1981
ip1981 commented Jun 18, 2014

the principle is that developer must be rigorous to his work and gentle to its users :-)

Than means:
1. -Wall -Werror in development environment (including travis)
2. No -Wall -Werror in cabal script

.travis.yml could be the solution suitable for all ;-)

@paulkoerbitz

-1

I think it's a bad idea to make this the default. While I agree that -Werror is a good idea in general I don't think travis should make this call for all projects. Also agree with @feuerbach that it violates the principle of least surprise.

@lunaryorn

I disagree as well, for reasons already given by others.

@hron84
hron84 commented Jun 18, 2014

"the principle is that developer must be rigorous to his work and gentle to its users :-)"

The developer, but not the CI system. CI system should be compatible with all developers' behavior and if it's means developer does not want -Werror then CI should silently agree it.

@ygale
ygale commented Jun 18, 2014

It's not hard to use -Werror in travis-ci without having that as the default and also without modifying the cabal file. Do something like this:

cabal install --only-dependencies --enable-tests
cabal install --ghc-options=-Werror --enable-tests
@quchen
quchen commented Jun 18, 2014
  • What @chrisdone said
  • If you want special behaviour write your own Travis config, that's what it's there for.

-1

@BanzaiMan
Travis CI member

Looks like the majority opinion is that this is a bad idea. I'm closing this.

Thank you for the input!

@BanzaiMan BanzaiMan closed this Jun 18, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.