Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

[Georg Rudoy]

пн, 20 апр. 2020 г. в 16:51, Michael Orlitzky <mjo@g.o>:
> 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