kubernetes-client/haskell

Issue with kubernetes-client dependency on time on Hackage

magthe opened this issue · 9 comments

magthe commented

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 commented

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 commented

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 commented

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 commented

@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 😄

  • 👍1
magthe commented

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.
  • 👍1
akshaymankar commented

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

jonschoning commented
  • 👍1
akshaymankar commented

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

/close

k8s-ci-robot commented

@akshaymankar: Closing this issue.

In response to this:

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. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.