[Haskell-community] Start thinking about system installation for users Maybe?

[Cynede]

There are known problems which developers regularry face with cabal-install
and stack brings easier and safer workflow for developers, that's true. But
I don't see how stack can help developers to understand other aspects

When haskellers talk about user installation they really mean sandbox
When haskellers talk about global installation they mean user installation
When haskellers talk about system installation their brains blows

People complain that on Haskell.org there is harmful workflow for
developers introducing Haskell Platform and it should be overtaken by
stack. (Note that Haskell Platform is system installation used by different
users and it can't be messed up with user installation)

However either `cabal-install` and `stack` worklows are both harmful for
users, `stack` does resolve nothing for user side, it just helps you with
sandbox managing during development stage.

I will try to explain.

Regularly users use package managers (on windows installers) to get what
they want, that's how users install python projects, C++ projects, etc...
users don't use pip (really they don't)

What about haskell? On most distributions and Windows users should use
what? sandboxes for every program and install those progam for every users
avoiding system installation?

Currently yes. Other ways will be harmful. There is solution from NixOS but
I doubt if they've managed to implement revdep rebuild for haskell
packages. I like (a lot) solution from gentoo where you can simply run
`emerge idris` and everything will be installed on system alike you install
some python util (alike portage itself). But even in Gentoo there is dirty
hack to manage haskell packages updates.

it looks really dirty

    haskell-updater -- --jobs="$(($(nproc) + 1))" --verbose-conflicts
--backtrack=100
    haskell-updater -- --jobs="$(($(nproc) + 1))" --verbose-conflicts
--backtrack=100

basically it's rebuilding all libs depending on changed one then depending
on depending incrementally

What is it even?

Haskell programs and libraries extensively reuse entitites (types,
functions, rewrite rules, type instances, other stuff) exported from
external libraries as non-opaque entities to allow aggressive cross-module
inlining to compile away deep layers of abstraction. It’s language’s
feature. If you accept the fact transitive dependencies being able to break
ABI is not a GHC bug

what actually affects real ABI (exported inlines, exported datatype layout
changes, modules names, strictness annotations, unpack pragmas) ghc
–show-iface can help in tracking ABI drift.

So in nutshell it's a feature but when we're fixing linkage for C/C++ we
can scan libs for missing shared library dependencies and attempts to fix
them by rebuilding broken libs
For haskell we hardly can detect ABI changes and the only way I know
currently is `haskell-updater` util and I'm still looking for better
solution

For example when one project, for example Idris, start using changed
(bumped) library which is shipped with GHC it feels absolutely fine on
sandbox But when user will install idris (and that library to system) all
other libraries will become broken because their dependencies is changed by
that That’s why some core packages has -compat compatibility layers Sure
developers tell me that they don’t care and everything works fine in
sandboxes and downgrading this library is distro-patch

Note that currently either cabal-install and stack has nothing to do with
atomic packages managing. Package manager can install, can remove, can
update, can track dependies changes and end with working environment
without sandbox replacing. Honestly it's very same situation with python or
perl with only difference... When I install software written on python I
don't need to use `pip` and `Haskell` seems like much harder to package but
people everywhere only force you to use really wrong solutions (including
community loved stack)

So my question is generally to community: are we even going to think in
direction of users or are we just focus on developers and their sandboxes?
In second case we need docker for each Haskell project.

Thanks for your attnetion, it's my first post to this mailing list and
sorry for my horrible English
Heather
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-community/attachments/20160422/9a8c403d/attachment.html>