Oleg Grenrus

> If such a tiny problem cannot be solved easily, then maybe some code in the Cabal code base needs to be refactored? I try to say **it should be...

> Imo the `cabal repl script` use of a ghci script was a hack on top of another hack (fake-package), and recognized as such. It was needed to implement a...

a side note: ghci will gain a multi-home-package functionality, but *then `:set` won't even work initially*. The problem is very similar to what's happening there, as far as i understand:...

Is `X@2013` conceptually different then `X >= 2000 && I think we would not need to store extra information. All the information to reconstruct the context at a certain point...

Note: FSF approves, but not recommends > We do not recommend this license. If you want a lax permissive license for a small program, we recommend the X11 license. A...

There is no guarantee that `phadej/foo` and `hasufell/foo` are anywhere close. (We have seen `lenz` package e.g.). Needing to fork a package is a social problem, switching the ecosystem to...

... and namespacing is a **very heavy** feature technically to introduce today. GHC knows and cares about package names, to begin with.

See https://github.com/haskell/cabal/pull/5314#pullrequestreview-124206793 Separate directory is not proper solution.

Fwiw, zinza branch is first step to refactor Paths_ module generation, so it would be easier to refactor. Something I briefly discussed with Moritz, that it could generate store-relative Paths_module...

IIRC there was discussion of doing file-embed-like thing, using linker object file + generated module. On mobile, so cannot look up if it is in some existing issue. The linker...