Parse warnings are blocking Hackage revisions

[parsonsmatt]

trafficstars

I want to make a revision to persistent-test to bump a major version bound. When I do so, I get this output:

This warning is irrelevant to the job that I am trying to accomplish here, and the UX for understanding/fixing/diagnosing is unclear. There are no line number indicators above. There's no autoformat fix option available.

Hackage server should not block a revision because of a warning (obviously errors should be blocked).

[Bodigrim]

-  default-language: Haskell2010
-  default-extensions:
+    default-language: Haskell2010
+    default-extensions:

...so that it matches indentation of build-depends: above.

[parsonsmatt]

Sure, which will be fixed with cabal-fmt later, but for now I still think warnings like this should not block revisions.

[gbaz]

"There are no line number indicators above." -- doesn't the line-number get listed as 93?

You're right having an autofmt fix would be better. Unfortunately cabal-fmt is an external heavyweight tool. I think we could improve this when, if ever, cabal finally lands an internal autoformat mechanism...

[parsonsmatt]

I think we can simply stop blocking revisions on parse warnings. They can be reported, sure, but blocking is unnecessary and harmful to UX.

There are no line numbers in the text box above the error message, so I need to copy the text into vim and see what is line 93.

[phadej]

This is an issue which will fix itself with time. The problem is that original file has inconsistent indentation, it got in Hackage before there were checks.

I wouldn't remove these warnings. They are there for the reason. The fact that inconsistent indentation is possible is very confusing quirk of the format.

TL;DR just fix it. It's rare, and will become rarer.

[parsonsmatt]

The entire point of revisions is to update an old thing. The next version of persistent-test will have cabal-fmt applied, but I don't care to implement that sort of autoformatting on my other projects.

Requiring formatting and indentation changes (that don't impact the parse of the file at all!) is very user-hostile behavior. I want to change a single number in a file, I do not want to grab the test, paste it to vim, run a formatter, re-upload the whole thing.

[gbaz]

what oleg means I believe is that if the package were uploaded today fresh, the check would prevent that syntax to begin with. so this problem only affects "legacy" cabal files on hackage.

[parsonsmatt]

That is also rather obnoxious! Is cabal-fmt going to be part of cabal anytime soon?

[phadej]

! Is cabal-fmt going to be part of cabal anytime soon?

Why would it? Its the same as asking when ormolu will be part of GHC.

[andreasabel]

I am also bitten by this new-fangled nonsense. I am trying to establish base < 4.8 bounds on the completely outdated greencard family (e.g. https://hackage.haskell.org/package/greencard-3.0.3) and I am now barred by hackage to do so, for these reasons:

• tabs instead of spaces
• inconsistent indentation
• too old cabal-versions
• ~~other bugs in the revision checker~~ (I'll report in another issue) #1377

This is outright silly!
The hole point of me trying to do these revisions is to clearly signal to cabal "this is old crap, do not even bother invoking GHC", and now hackage blocks me from cleaning its database up like this.

[ulysses4ever]

nonsense

this is exactly right definition of the situation when a warning (not an error) is blocking something. This should be fixed: warnings are good but they shouldn't block anything.