Source
r/haskell•
avanov

Unreasonable Hackage requirement

I don't see a good reason why Hackage should insist that I manually activate -Wall -Werror in my dev environment, as it is my intention to never let new versions of GHC to swallow warnings. It helps early discovery, as it promotes early reports and proper reaction on changes from other people.

http code 400
Error: Invalid package

'ghc-options: -Wall -Werror' makes the package very easy to break with future
GHC versions because new GHC versions often add new warnings. Use just
'ghc-options: -Wall' instead. Alternatively, if you want to use this, make it
conditional based on a Cabal configuration flag (with 'manual: True' and
'default: False') and enable that flag during development.
make: *** [Makefile:30: release] Error 1

Posted Aug 12, 2021, 1:42 PM UTC · edited

152
ephrion•

Enabling -Werror for libraries can only harm your users. It provides literally no benefit to them.

It's easy enough to build with -Werror locally or in CI. With cabal, you can a cabal.project that sets -Werror for your package without putting it in the .cabal file.

package foo
  ghc-options: -Werror

(cf this issue)

Likewise, with stack, you can do stack build --ghc-options "-Werror" or stack build --pedantic or add a line in the stack.yaml.

31
avanovOP•

Yes, I know that packages could have optional stanzas based on manual flags.

But! How exactly is it harming users, if the package being published with non-optional -Werror has never been used by them yet, and that all future warning-errors are supposed to be handled early with CI that use dev versions of GHC (i.e. way earlier than any user relying on the package in production could install it)?

-6
ephrion•

Yes, I know that packages could have optional stanzas based on manual flags.

Not even that - you can keep your .cabal file clean of any optional/manual configuration flags and still have -Werror in local builds. All build tools support this.

But! How exactly is it harming users, if .............

So, you acknowledge that it harms users if you don't do those things. Got it!

It's a simple cost-benefit analysis.

There is no benefit to end-users for a library to have -Werror enabled in the .cabal file. There is some cost - the library may fail to build with some untested GHC configuration due to different behavior of -Wall.

There is some benefit to the library maintainer to have -Werror in the .cabal file. Namely, they do not need to have a configuration setting for local development and CI. With modern stack and cabal use, this is literally a single file with ~1-2 lines of config to enable -Werror. Same with nix - it is trivially easy to get -Werror overlaid on your build. There are a lot of costs - keeping a codebase -Wall clean across multiple GHC releases is a pretty massive undertaking with a lot of work in CI and a lot of CPP (which itself introduces build complexity and exhaustiveness problems).

BenefitCost
End UserNoneLots
MaintainerLittleLots
16
avanovOP•

So, you acknowledge that it harms users if you don't do those things. Got it!

No I don't acknowledge it on general terms. I assumed it might be in the current status-quo situation where -Werror is not advocated for in too many of the packages that should have had it in the first place, similarly to unsafePerformIO in unreasonable places that could easily avoid it with just an extra bit of effort.

So, I'd like to ask you my original question again - how exactly is it going to harm users if it wasn't the the current status-quo situation, and if I used the described pipeline with Dev GHC in all my CI instances?

There are a lot of costs - keeping a codebase -Wall clean across multiple GHC releases is a pretty massive undertaking with a lot of work in CI and a lot of CPP (which itself introduces build complexity and exhaustiveness problems)

Fine, I am willing to pay this cost. Why am I not allowed to publish my package under these conditions?

-1
ephrion•

okay, again

  • Cost to end users: Yes
  • Benefit to end users: No

Why should end users want this? Why should Hackage - a platform that exists to serve the end users primarily - allow this?

12
Lemmih•

The stated reason isn't good enough? Would the suggested solution work for you?

9
avanovOP•

it's not good enough because it's a viewpoint that gatekeeps packages with different viewpoints regarding these GHC flags to compete in the realm of ideas and approaches, and to practically prove certain points about package maintainability with future GHC releases. Yes, they "make the package very easy to break with future GHC versions", but it doesn't explain why this option is not allowed on Hackage.

-7
friedbrice•

If you want to compete in the realm of ideas, there's nobody stopping you from hosting your own package repository. Have fun!

8
avanovOP•

Are you interested in growing the comminity (something that I regularly hear from the Haskell foundation and am personally trying to participate in publishing real-world packages on the officila Hackage) or just want to check my ability to deploy my own Haskell infrastructure? I'm actually assessing my options already - https://github.com/input-output-hk/iohk-nix/issues/493 - and it's not that I'm afraid of fractioning of data sources.

-8
machinedgod•

am personally trying to participate in publishing real-world packages on the officila Hackage

But you aren't - you're trying to promote packages that community doesn't consider "real-world", and ephrion explained to you -patiently and factually- why, with cost/benefit analysis.

If you disagree, that is of course alright (and often, encouraged), but as friedbrice said - the best course is to create your own repository of packages. Why not?

In the end, the users/clients of your library will be the deciding factor.

11
[deleted]•

[deleted]

3
otulp•

I don’t know what else to say, other than that it does seem reasonable to me, and based on experience. Your suggested flags would introduce noise and demand precious time from more people.

5
avanovOP•

Your comment and the assumption that it will take more time is predicated on the idea that unmaintainable packages should compile under any random number of subsequent future GHC versions, which is a weird metric to me - firstly, because it will eventually not compile, even without the flags I’m advocating for, due to dependecy resolver versions mismatch, and it might be the next upcoming GHC release, and secondly, if the package is unmaintained and popular then it is in comminity’s interest to discover this fact as early as possible and decide on new maintainers sooner than later.

Another reason for your position could be the fact that under this flag a developer actually needs to care about incomplete patterns, dangling dependencies and so forth, but that could also be an argument in favour of code quality.

0
otulp•

Yes, I assume that packages should keep working without modification even if GHC should introduce a warning about some upcoming incompatibility into -Wall.

No, I don’t assume unmaintainable packages should compile under any random number of subsequent future GHC versions.

Not sure if you’re implying something in the latter part. I’m all for keeping the code squeaky clean.

Best of luck to you in the future.

2
avanovOP•

Yes, I assume that packages should keep working without modification even if GHC should introduce a warning about some upcoming incompatibility into -Wall.

why do you assume that ALL packages unilaterally should keep working if GHC introduces a new warning? Would you like the warning be swallowed in all cases, including mission critical one where safety of the system and, potentially, people might depend on it and it's better to assess it before deploying it on a new GHC version? Why shouldn't packages with these default compilation expectations be allowed in Hackage uploads?

2
otulp•

Because of risk analysis.

3
avanovOP•

I'd like to summarise the results here:

u/emilypii u/jaspervdj u/goldfirere u/bgamari u/edwardkmett I think I can save Haskell Foundation a few days of research into why the community is not growing as much as it could be and what are the reasons for poor adoption of the tooling in a wider audience. This reddit subset of the community is unable to take criticism seriously, they would rather evade proper critical re-evaluation of the past decisions in the light of newcomers expressing their frustration with the restrictions that are demonstrably affecting the ability to upload safer packages that don't block anyone else. And the arguments they provide are just serving to support the status-quo, with not a single attempt to provide a reproducible example of the issues they claim to deem to happen if stricter flags are allowed on Hackage.

If the Foundation is really interested in bringing more people into the ecosystem, it should realise and promote in boards like this the idea that more people in the community means more use-cases and wider views on what should be recognised and allowed as legitimate cases not fitting the current implementations; and that the people who voluntarily took the burden of responsibility for the available central tooling should not be overly sensitive and protective when criticism of the current implementation is expressed strongly and publicly.

-5†