пн, 20 апр. 2020 г. в 16:51, Michael Orlitzky <m...@gentoo.org>: > Except that Haskell as a research language tends to inspire more "fire and > forget" software.
I'd say this is not the case for the last few years, but that's maybe just my own impression from interacting with > (And Haskell works better in Gentoo than anywhere else, in my opinion.) Totally agreed here. That's one of the main reasons I run Gentoo (especially before dev-haskell/stack emerged upstream a few years ago). > You package each dependency as a separate package. If there's a conflict > between two packages, then... you can't have those two packages > installed together. When that happens, you alert upstream, and try to > convince them to be more lenient with their dependencies (again, nothing > Haskell-specific here). Sometimes that involves code changes, but often > it's just an edit to the cabal file. Many people follow either semver or > the PVP (https://pvp.haskell.org/) which keeps things from getting too > far out of control. I'd say the Haskell-specific thing is the presence of stackage LTS releases that people tend to stick to. For instance, beam-postgres disappeared in recent LTSes, so some projects of mine are stuck on older LTSes (adding that to extra-deps was a pain for reasons I don't remember at the moment), while the others can happily use the new ones. Libraries incompatibilities are just a matter of time in this case. Sure, hacking on .cabal/package.yaml is one way to solve this, but I wasn't sure it's reasonably robust in the long run. Anyway, thanks for your feedback. This probably means I should stop thinking about the general case and maybe start playing around with packaging stuff, and then seeing where it breaks. > If upstream absolutely insists on minor-version dependencies, then you > either tolerate it conflicting with everything else, or leave it out of > the tree. You probably shouldn't even be packaging a library whose API > is distinguishable across minor releases. That's not a matter of just the API per se. Even the library file name encodes its deps in its name (if I understand correctly, that's the hash in libHSregex-base-0.94.0.0-541xQVwwNRiBGjsNKmOPoy-ghc8.6.5.so for example). Personally I just find it hard to reason about this sort of dependencies management. But, again, I should probably avoid trying that and just jump head first to packaging. > I don't see anything fundamentally different here > between Haskell (or Go, or...) Dunno much about Go and I don't have a single Go package locally to check. Do they do static or dynamic linking with the deps, for instance? What's the language model wrt API and linking? > and C. More stable API (and ABI). -- Georg Rudoy
