Issue with kubernetes-client dependency on time on Hackage

[magthe]

I'm not sure what's happened, but kubernetes-client 0.2.0.0 available on Hackage has a dependency on time ==1.8.*, which makes it difficult to build with GHC 8.8 (8.8.4 has time 1.9.3). I'm not completely sure why the generated Cabal file has that version bound though, because the package.yaml clearly states a dependency on time >=1.8.

I just ran hpack(version 0.34.2) manually on the package.yaml and the generated Cabal file is correct, i.e. a dependency on time >=1.8. So basically I'm confused about this...

Would someone please take pity on us Hackage users and adjust the dependency in the Cabal file?

[akshaymankar]

This happened due to generating bounds with stack while uploading to hackage. So, if you run stack sdist --pvp-bounds both, it would generate a cabal file with time ==1.8.*. In general, I think upper bounds are fairly annoying because of issues like this.

As for updating hackage, there was a recent merge, so I was going to upload another version anyway. Maybe this time I can just not generate upper bounds while uploading.

WDYT @jonschoning @guoshimin?

[jonschoning]

I think it may make more sense to have the bounds be the same as the package.yaml. If there's a need to include an upper bound, lets include that in package.yaml as well. Personally I tend to adjust upper bounds manually so I don't have much experience with how --pvp-bounds generates the values.

[akshaymankar]

Using --pvp-bounds to generate upper bounds just puts upper bound to be less than the next major version (according to PVP, not semver). This is the safest choice according to PVP.

We could just put the upper bounds manually, but I am not sure how would we choose a good upper bound for a given dependency. How do you do it?

Since, I don't have a way, I just remove all upper bounds until something breaks. When I face such problem, I can either fix the code to work with both version or I can just put an upper bound depending on effort of it. If we put both of our packages on stackage, we could get notified every time we have a problem with one of our dependencies.

[akshaymankar]

@magthe I have published a new revision of kubernetes-client-0.2.0.0 on hackage to unblock you until we decide how to deal with upper bounds. Thank you for bringing our attention to it :smile:

[magthe]

One way to deal with it in the future could be to

1. Generate without upper bounds and upload to Hackages
2. When finding that a new version of a dependency breaks the build, add an upper bound on Hackage only (via the "edit package information" link on the package's Hackage page)
3. Make the necessary changes upstream, and start over from 1.

[akshaymankar]

@jonschoning Is it ok if we do it as @magthe says?

[jonschoning]

sounds good to me

On Mon, Sep 14, 2020, 1:10 PM Akshay Mankar notifications@github.com wrote:

@jonschoning https://github.com/jonschoning Is it ok if we do it as @magthe https://github.com/magthe says?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kubernetes-client/haskell/issues/77#issuecomment-692223883, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABBPXZOFXOJ6NVCCWJ72UTSFZMDBANCNFSM4Q63FBGQ .

[akshaymankar]

I also published the the latest version. I will close this issue now.

/close

[k8s-ci-robot]

@akshaymankar: Closing this issue.

In response to [this](https://github.com/kubernetes-client/haskell/issues/77#issuecomment-699480043): >I also published the the latest version. I will close this issue now. > >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.