Open Ericson2314 opened 7 years ago
Sorry, I don't understand this issue, can you give an example how you want things to be?
Sorry for not responding earlier. Also I realized I misunderstood transformers-compat
in that it works in the opposite fashion.
The goal is say I have a library foo, with releases versions 0.1.9.0
and 0.2.0.0
. But I don't want to leave my 0.1.x.y
users high and dry, and I only broke a few interfaces in 0.2.0.0
. The purpose of this feature would be to allow me to write a 0.1.10.0
that depends on 0.2.*.*
and mostly reexports compatible definitions, but wraps/replaces incompatible ones when necessary.
@phadej Ah, I just discovered https://github.com/haskell/cabal/blob/b32cfbcfce46f4232e9ff1a5cda3d895b9cd6ce7/cabal-install/Distribution/Solver/Types/PackagePath.hs#L49 I think what I want is a generalization of this, to allow any package depending on a new generation of itself.
I.e. you want to have
name: mylib
version: 0.1.10
library:
build-depends: mylib >= 0.2 && <0.3
IMHO it's not worth it. There are quite a lot of difficulties (with shadowing modules, types, you cannot shim classes/instances anyway). I'd just create a compat library (in either direction).
Also, transformers-compat
works around a problem maybe not so obvious: in some setups transformers
isn't upgradeable (i.e. if you depend on ghc
lib).
And indeed, transformers-compat
adds functionality to old transformers
, which is introduced in the new one.
And e.g. Data.Functor.Classes
is an example of a module you cannot shim, even if you want very very much. (huge difference between trransformers-0.4
and transformers-0.5
/ base-4.9
).
I'd love to ditch names like
transformers-compat
and instead allow libraries to declare private dependencies on new versions of themselves.The harder part of this is private dependencies of course but https://github.com/haskell/cabal/pull/4104 also helps in that by making version bounds that exclude internal components and error today. That way tomorrow we are free to assign brand new meaning to them (i.e. actually depend on a newer version of me, please) tomorrow without breaking any existing packages.