Skip to content

Run or suggest cabal check #12

@sellout

Description

@sellout

Hackage rejects packages for various reasons. The cabal check command reports those reasons. AFAICT, they’re not included in the failure response from Hackage. I recently had this action fail, and only got

Uploading no-recursion-0.3.0.0 to http://hackage.haskell.org/packages/upload
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
 98 26146    0     0  100 25800      0   130k --:--:-- --:--:-- --:--:--  131k
curl: (22) The requested URL returned error: 400

I ran cabal check locally and got

The following errors will cause portability problems on other environments:
Error: [missing-bounds-setup] The dependency 'setup-depends: 'Cabal' does not
specify an upper bound on the version number. Each major release of the
'Cabal' package changes the API in various ways and most packages will need
some changes to compile with it. If you are not sure what upper bound to use
then use the next major version.
Error: Hackage would reject this package.

It would be great if this action reported something like “Hackage may have rejected this package. Run cabal check in the directory with your package’s Cabal file to see if there are any issues.” when there’s a 400.

It would also be helpful if the ran cabal check (either proactively or maybe only after such a failure) to report the reason to the user. (Even if it does this, it should still recommend the user run cabal check on their own – better to figure it out before the push to Hackage fails.)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions