phadej / tdigest

On-line accumulation of rank-based statistics such as quantiles and trimmed means
30 stars 7 forks source link

Relax lower version bounds on some dependencies #25

Closed maoe closed 6 years ago

maoe commented 6 years ago

I have a project that still uses GHC 7.10.1 with some old libraries. This PR is to allow tdigest/tdigest-Chart to comiple with that compiler and libs. I've confirmed locally that the following commands worked fine:

cabal new-configure --constraint='vector==0.10.12.3' --constraint='base-compat==0.9.1' --constraint='semigroupoids==5.1' --constraint='semigroups==0.18.2' --constraint='lens==4.15.1' --constraint='Chart==1.8.1' --constraint='dual-tree==0.2.1.1' --enable-tests
cabal new-test all

The constraint for dual-tree is necessary because the latest version doesn't compile with newtype-generics < 0.5.3.

phadej commented 6 years ago

Sorry, I have no reason to relax and support lower lower-bounds.

If you are using old Stackage snapshot

tdigest compiles fine with bundled dependencies of GHC-7.8.4, and will so until there's very good reason to drop that support (5 major GHC versions ATM!). However, I have no interest in supporting old Stackage snapshots, the LTS in the name is misleading.

phadej commented 6 years ago

similarly, but better, for cabal new-build, you can use --allow-older:

cabal new-build --allow-older='tdigest:base-compat' --allow-older='tdigest-Chart:base-compat' --constraint='base-compat==0.9.1' tdigest --dry
Build profile: -w ghc-8.2.2 -O1
In order, the following would be built (use -v for more details):
 - base-compat-0.9.1 (lib) (requires download & build)
 - reducers-3.12.2 (lib:reducers) (requires build)
 - tdigest-0.2 (lib:tdigest) (first run)

or you can write those to cabal.project

allow-older:
  tdigest:base-compat,
  tdigest-Chart:base-compat
  -- etc

Sorry, if I hastly commented like a jerk.

phadej commented 6 years ago

Ironically,

$ trustee matrix dual-tree-0.* -c 'newtype-generics < 0.5.3
                    8.4.1  8.2.2  8.0.2  7.10.3  7.8.4  7.6.3  7.4.2  7.2.2  7.0.4
dual-tree-0.2.2/    FAIL   FAIL   FAIL   FAIL    FAIL   FAIL   NO-IP  NO-IP  NO-IP
dual-tree-0.2.1.1/  OK     OK     OK     OK      OK     OK     NO-IP  NO-IP  NO-IP 
dual-tree-0.2.1/    NO-IP  OK     OK     OK      OK     OK     NO-IP  NO-IP  NO-IP

with an errors

src/Data/Tree/DUAL/Internal.hs:62:1: error:
    Could not find module ‘Control.Newtype.Generics’
    Use -v to see a list of the files searched for.
   |
62 | import           Control.Newtype.Generics
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

http://hackage.haskell.org/package/dual-tree-0.2.2/changelog says for 0.2.2

- switch from deprecated Control.Newtype to C.N.Generics

but build depends are

newtype-generics >= 0.5 && < 0.6,

when http://hackage.haskell.org/package/newtype-generics-0.5.3/changelog says only for 0.5.3

All code was moved to a new Control.Newtype.Generics module.

So I hope I have a point of not relaxing lower bounds, if I don't test them continuously.


I'll make Hackage Trustee duties soonish.

phadej commented 6 years ago

dual-tree corrected: https://github.com/diagrams/dual-tree/pull/10

maoe commented 6 years ago

Thanks for fixing the dual-tree and reviewing the PR.

If you are using old Stackage snapshot

No, I'm not. We're using an in-house build system (based on Shake) with all dependencies checked in. So I can modify the tdigest's bounds locally then check in. This PR was a (slight) hope for not having it to deviate from upstream, but that's okay.

phadej commented 6 years ago

@maoe cool! btw, is there a reason you don't use 7.10.3?

maoe commented 6 years ago

@phadej IIRC It's a performance reason. I don't remember exactly how much it was slow though.