Re: [haskell art] haskell dependency management over time
Hi Miguel, I agree that this sounds right. In practice, what do you imagine that implies in terms of system sprawl? I mean, I would imagine one is at least tripling or quadrupling the Haskell footprint. I'm afraid this is probably edging up to a general question about art preservation maintenance. I don't mean to go off-topic. But for instance, supposing one feels obligated to stash the OS as well -- say one works in a Linux that has a rolling release schedule -- then infrastructure grows in turn. At such point, I suppose one could archive snapshots of systems with little Haskell environments per-piece. One VM could archive a number of pieces if each were of a modest size. Al On Wed, Jul 2, 2014 at 5:54 AM, Miguel Negrão miguel.negrao-li...@friendlyvirus.org wrote: ― Attachment links are at the end of this email ― Em 01-07-2014 16:17, Al Matthews escreveu: Hello .. I find Haskell package-management to be a bit of a dark art. In particular, what I find, is that it is easy to break things on which I rely. This is compounded no doubt by my use of several development platforms. Still, I wonder if anyone has recommendations on using hsenv, or capri, or cabal-dev, or similar. One goal I think, could be to archive a minimal working environment for any given major piece. But I don't know if this is a heavy-handed approach, and as such, I ask in particular for your experience with maintaining Haskell code and systems over time. Thanks, Al Hi Al, I would recommend installing only the bare minimum of packages system wide (global and for your user), for instance just the haskell platform, and install everything else via cabal sandboxes. This way it will be unlikelly that you get into trouble again. Another option is using the nix package manager which can sandbox the whole haskell infrastructure, including multiple version of ghc, etc. best, -- Miguel Negrão http://www.friendlyvirus.org/miguelnegrao Haskell Art now contains the following file http://lurk.org/r/file/hbDVNn6p5ECCYUKozgqyIB63Qij-8G-2thFMqY Name: signature.asc Type: application/pgp-signature Size: 0KB -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/18U8WkSuHQFTYw24Vd1QVR To leave Haskell Art, email haskell-...@group.lurk.org with the following email subject: unsubscribe -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/6eW5THmbuNnfdSCNyK3c3u To leave Haskell Art, email haskell-...@group.lurk.org with the following email subject: unsubscribe
Re: [haskell art] haskell dependency management over time
― Attachment links are at the end of this email ― Em 02-07-2014 14:14, Al Matthews escreveu: Ah .. I see .. nix would obviate much of that work. Thanks for the reference. On Wed, Jul 2, 2014 at 9:09 AM, Al Matthews prolep...@gmail.com wrote: Hi Miguel, I agree that this sounds right. In practice, what do you imagine that implies in terms of system sprawl? I mean, I would imagine one is at least tripling or quadrupling the Haskell footprint. Yes, that and cpu cycles wasted in compiling is the price to pay for no cabal hell. Storage is cheap these days, though... I'm afraid this is probably edging up to a general question about art preservation maintenance. I don't mean to go off-topic. But for instance, supposing one feels obligated to stash the OS as well -- say one works in a Linux that has a rolling release schedule -- then infrastructure grows in turn. At such point, I suppose one could archive snapshots of systems with little Haskell environments per-piece. One VM could archive a number of pieces if each were of a modest size. nix would make this quite easy probably, since it makes it quite easy to replicate a whole system configuration. Also, within just one system you can have a haskell setup per project completelly separate. There are some caveats. I did have issues when using cabal with nix, it seems cabal cannot find the libraries correctly in some situations, which means you should just use ghc instead (either directly or via nix-build). Also, nix does not solve the problem of cabal hell directly, since it just keeps a fixed seleciton of haskell packages (like stackage) in it's repository, if you can't use the version there either you have to add the versions you need to the repository (through some .nix files) or you have to use cabal sandboxes and let cabal figure it out. best, Miguel Haskell Art now contains the following file http://lurk.org/r/file/7pebO1VXzI5gtxXYQicdDXuBd1E-8G-2thMnfr Name: signature.asc Type: application/pgp-signature Size: 0KB -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/ynqkDD6Om6CrN0u7VBoJg To leave Haskell Art, email haskell-...@group.lurk.org with the following email subject: unsubscribe
Re: [haskell art] haskell dependency management over time
Am 01.07.2014 17:17, schrieb Al Matthews: Hello .. I find Haskell package-management to be a bit of a dark art. Do you mean management as a maintainer or as a user? For maintainers I wrote some scripts: http://hackage.haskell.org/package/cabal-scripts http://hackage.haskell.org/package/darcs-scripts However, updating many packages for new major releases of basic packages like 'transformers' or new Cabal features or new GHC features, still costs lot of time. As a user I have not tried cabal-dev and friends. I am just using 'cabal' and since there are so many versions of the packages and GHC around, many packages are installed multiple times (in different package and GHC versions) on my machine, such that the dependency hell hardly occurs. -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/5IaQGgN0fuNugfHYLDkgSk To leave Haskell Art, email haskell-...@group.lurk.org with the following email subject: unsubscribe
Re: [haskell art] haskell dependency management over time
Am 01.07.2014 17:27, schrieb Henning Thielemann: As a user I have not tried cabal-dev and friends. I am just using 'cabal' and since there are so many versions of the packages and GHC around, many packages are installed multiple times (in different package and GHC versions) on my machine, such that the dependency hell hardly occurs. I should add, that installing multiple packages at once with 'cabal install' fixes package incompatibilities in many cases. -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/7e0vem43LgDpzKXOaGCmrK To leave Haskell Art, email haskell-...@group.lurk.org with the following email subject: unsubscribe
Re: [haskell art] haskell dependency management over time
Thank you Hans, and Henning. I like that they refer to the problem as cabal hell. On Tue, Jul 1, 2014 at 11:23 AM, Hans Höglund h...@hanshoglund.se wrote: Nowadays you can do this with Cabal sandboxes. See more info here http://coldwa.st/e/blog/2013-08-20-Cabal-sandbox.html Regards, Hans - Hans Hglund Composer, conductor and developer hans [at] hanshoglund.se hanshoglund.com https://twitter.com/hanshogl https://soundcloud.com/hanshoglund http://github.com/hanshoglund On 1 jul 2014, at 17:17, Al Matthews wrote: Hello .. I find Haskell package-management to be a bit of a dark art. In particular, what I find, is that it is easy to break things on which I rely. This is compounded no doubt by my use of several development platforms. Still, I wonder if anyone has recommendations on using hsenv, or capri, or cabal-dev, or similar. One goal I think, could be to archive a minimal working environment for any given major piece. But I don't know if this is a heavy-handed approach, and as such, I ask in particular for your experience with maintaining Haskell code and systems over time. Thanks, Al -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/5WOMd5puueRAlYg0kOcnPp To leave Haskell Art, email haskell-...@group.lurk.org with the following email subject: unsubscribe -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/4IsGjyggVUCDO6cxEGBITI To leave Haskell Art, email haskell-...@group.lurk.org with the following email subject: unsubscribe -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/3oUTQ9w0P1f110mrzkFwpR To leave Haskell Art, email haskell-...@group.lurk.org with the following email subject: unsubscribe
