4 ms·

How I deploy Haskell Code

62 points by lelf 11y ago

marcosdumay 11y ago
To be honest, I'm more interested on what the author did before he switched than on how he does things now. A "How I deploy Haskell Code" post gathered my attention just because it's a problem I never expected anybody to have, just like "How I deploy C Code".
- seagreen 11y ago
  Fair question:) GHC binaries dynamically link certain C libraries, which must be present (and in the right version range) at runtime. This can cause trouble. I'd be curious to hear if there's a convenient way to build an entirely statically linked GHC binary. I've searched around some but haven't found an easy answer yet.
  - dhess 11y ago
    You'll find this Reddit thread useful: https://www.reddit.com/r/haskell/comments/3kjpwe/how_to_easily_create_portable_binaries_for_linux/ https://www.reddit.com/r/haskell/comments/3kjpwe/how_to_easi...
    - seagreen 11y ago
      Sweet, thanks!
  - arianvanp 11y ago
    https://github.com/nilcons/ghc-musl https://github.com/nilcons/ghc-musl Uses musl to create fully statically linked binaries
    - seagreen 11y ago
      Slick, thanks!
  - prodigal_erik 11y ago
    Not sure about .deb format, but rpmbuild will automatically add dependencies on packaged shared libraries using their sonames: http://www.rpm.org/max-rpm/s1-rpm-depend-auto-depend.html http://www.rpm.org/max-rpm/s1-rpm-depend-auto-depend.html If you smuggle unpackaged code onto a QA or build machine, IMHO you asked for whatever happens to you.
  - thinkpad20 11y ago
    You can use nix to do your package management. It has many features and advantages (build speed, deterministic build environments, language agnosticism, etc), but specific to what you brought up it makes it trivial to declare a runtime dependency of package A on package B, and guarantee that as long as package A is installed, that package B will be as well, and be accessible to A. I believe it's pretty popular in the Haskell community; I do all of my Haskell development with it and use it with Python at work, where it's slowly starting to gain traction at my company.
    - seagreen 11y ago
      Hello from NixOS:) (https://github.com/seagreen/vivaine https://github.com/seagreen/vivaine) I don't think nixpkgs is a direct solution to this problem though. (A) Sometimes you're stuck with cabal-install because the rest of the people in the project use it. Nixpkgs includes many different sets of haskell packages, but isn't designed to pull in arbitrary versions of lots of different haskell packages by default. (B) Even if the rest of the team was using a set of haskell packages compatible with one of the Nixpkgs sets, it still involves extra work to figure out what C libraries the computer you're deploying to has, and then to make sure they're packaged for Nixpkgs and build with them. I think Nixpkgs and NixOS are _fantastic_ tools, but they aren't a panacea for all haskell deployment solutions.
      - thinkpad20 11y ago
        Well I certainly wouldn't call anything a panacea, but I'm not sure I'd fully agree with either of those criticisms. Having other people in the project use cabal install -- well, you can't blame a tool for other people not using it. It's true that nixpkgs doesn't track multiple versions of packages, but using the existing tooling (cabal2nix) it should be possible to fix down the versions you need. Towards the second point, nix isn't meant to figure out what C libraries you need; it's meant to let you specify exactly what those are and be confident that those will be respected.
- davmre 11y ago
  Haskell is actually great for writing certain types of web services. You can get close to C-level speed, but with the security and correctness guarantees of strong static type checking. Obviously it has its own warts (performance optimization requires a certain amount of black magic), but in a lot of cases it Just Works™ and does so much faster and more reliably than a typical dynamic language.
twblalock 11y ago
I hope that Docker will increase the popularity of languages like Haskell by taking away most of the problems with deployment and dependency management. If I can just create a Docker container for my ops team to deploy, without them needing to know what is inside of it, I can pretty much use any language I want.
- merlincorey 11y ago
  > If I can just create a Docker container for my ops team to deploy, without them needing to know what is inside of it, I can pretty much use any language I want. If you can get them to deploy anything you want without them needing to know what is inside of it... your ops team is too trusting, in my opinion.
  - twblalock 11y ago
    You think your ops team really knows what they are pushing? Whether you are deploying jar files, Debian packages, or Docker containers, or whatever else, the ops people rarely look inside. Their main concerns are security and performance, and those can be audited using black-box testing. Code quality has to be enforced by engineers, because ops people are not capable of doing code reviews.
    - merlincorey 11y ago
      > because ops people are not capable of doing code reviews That's probably specific to your organization.
      - davelnewton 11y ago
        Not really. Ops people are generally just that. Even DevOps aren't the ones writing the apps. Except for one specific place, nowhere I've worked in the last 25 years has Ops people that would be qualified to review either the apps or the libraries it uses. PenTests and security is a pretty different thing than app dev. And both are different than ops. Only recently have the roles been blurred, but even now, I see truly cross-functional people very rarely.

62 points by lelf 11y ago

To be honest, I'm more interested on what the author did before he switched than on how he does things now. A "How I deploy Haskell Code" post gathered my attention just because it's a problem I never expected anybody to have, just like "How I deploy C Code".

seagreen 11y ago
Fair question:) GHC binaries dynamically link certain C libraries, which must be present (and in the right version range) at runtime. This can cause trouble. I'd be curious to hear if there's a convenient way to build an entirely statically linked GHC binary. I've searched around some but haven't found an easy answer yet.
- dhess 11y ago
  You'll find this Reddit thread useful: https://www.reddit.com/r/haskell/comments/3kjpwe/how_to_easily_create_portable_binaries_for_linux/ https://www.reddit.com/r/haskell/comments/3kjpwe/how_to_easi...
  - seagreen 11y ago
    Sweet, thanks!
- arianvanp 11y ago
  https://github.com/nilcons/ghc-musl https://github.com/nilcons/ghc-musl Uses musl to create fully statically linked binaries
  - seagreen 11y ago
    Slick, thanks!
- prodigal_erik 11y ago
  Not sure about .deb format, but rpmbuild will automatically add dependencies on packaged shared libraries using their sonames: http://www.rpm.org/max-rpm/s1-rpm-depend-auto-depend.html http://www.rpm.org/max-rpm/s1-rpm-depend-auto-depend.html If you smuggle unpackaged code onto a QA or build machine, IMHO you asked for whatever happens to you.
- thinkpad20 11y ago
  You can use nix to do your package management. It has many features and advantages (build speed, deterministic build environments, language agnosticism, etc), but specific to what you brought up it makes it trivial to declare a runtime dependency of package A on package B, and guarantee that as long as package A is installed, that package B will be as well, and be accessible to A. I believe it's pretty popular in the Haskell community; I do all of my Haskell development with it and use it with Python at work, where it's slowly starting to gain traction at my company.
  - seagreen 11y ago
    Hello from NixOS:) (https://github.com/seagreen/vivaine https://github.com/seagreen/vivaine) I don't think nixpkgs is a direct solution to this problem though. (A) Sometimes you're stuck with cabal-install because the rest of the people in the project use it. Nixpkgs includes many different sets of haskell packages, but isn't designed to pull in arbitrary versions of lots of different haskell packages by default. (B) Even if the rest of the team was using a set of haskell packages compatible with one of the Nixpkgs sets, it still involves extra work to figure out what C libraries the computer you're deploying to has, and then to make sure they're packaged for Nixpkgs and build with them. I think Nixpkgs and NixOS are _fantastic_ tools, but they aren't a panacea for all haskell deployment solutions.
    - thinkpad20 11y ago
      Well I certainly wouldn't call anything a panacea, but I'm not sure I'd fully agree with either of those criticisms. Having other people in the project use cabal install -- well, you can't blame a tool for other people not using it. It's true that nixpkgs doesn't track multiple versions of packages, but using the existing tooling (cabal2nix) it should be possible to fix down the versions you need. Towards the second point, nix isn't meant to figure out what C libraries you need; it's meant to let you specify exactly what those are and be confident that those will be respected.
davmre 11y ago
Haskell is actually great for writing certain types of web services. You can get close to C-level speed, but with the security and correctness guarantees of strong static type checking. Obviously it has its own warts (performance optimization requires a certain amount of black magic), but in a lot of cases it Just Works™ and does so much faster and more reliably than a typical dynamic language.

twblalock 11y ago

I hope that Docker will increase the popularity of languages like Haskell by taking away most of the problems with deployment and dependency management. If I can just create a Docker container for my ops team to deploy, without them needing to know what is inside of it, I can pretty much use any language I want.

merlincorey 11y ago
> If I can just create a Docker container for my ops team to deploy, without them needing to know what is inside of it, I can pretty much use any language I want. If you can get them to deploy anything you want without them needing to know what is inside of it... your ops team is too trusting, in my opinion.
- twblalock 11y ago
  You think your ops team really knows what they are pushing? Whether you are deploying jar files, Debian packages, or Docker containers, or whatever else, the ops people rarely look inside. Their main concerns are security and performance, and those can be audited using black-box testing. Code quality has to be enforced by engineers, because ops people are not capable of doing code reviews.
  - merlincorey 11y ago
    > because ops people are not capable of doing code reviews That's probably specific to your organization.
    - davelnewton 11y ago
      Not really. Ops people are generally just that. Even DevOps aren't the ones writing the apps. Except for one specific place, nowhere I've worked in the last 25 years has Ops people that would be qualified to review either the apps or the libraries it uses. PenTests and security is a pretty different thing than app dev. And both are different than ops. Only recently have the roles been blurred, but even now, I see truly cross-functional people very rarely.