Haskell DevOps

Open-source Haskell projects categorized as DevOps | Edit details

Top 23 Haskell DevOps Projects

  • GitHub repo Cabal

    Official upstream development repository for Cabal and cabal-install

    Project mention: Why doesn't Haskell have a package manager? | reddit.com/r/haskell | 2022-01-09

    I just found some more info: this functionality is provided by the third party cabal-edit tool. This is the specific issue that tracks the integration of that functionality into cabal itself. One of the problems of the cabal-edit tool is that it sometimes messes up your cabal files. We need the exact-printing to avoid that.

  • GitHub repo aur

    A secure, multilingual package manager for Arch Linux and the AUR.

    Project mention: Yay or Paru!!?? | reddit.com/r/archlinux | 2022-01-05
  • Scout APM

    Less time debugging, more time building. Scout APM allows you to find and fix performance issues with no hassle. Now with error monitoring and external services monitoring, Scout is a developer's best friend when it comes to application development.

  • GitHub repo hackage-server

    Hackage-Server: A Haskell Package Repository

    Project mention: Haskell compiled onto LLVM increase performance? | reddit.com/r/haskell | 2021-11-02

    The other source of haskell documentation is hackage, which features both libraries and higher-level GHC modules. Using hoogle (!hoogle or !hgl in DDG), you can search these docs by module name, function name, or even type signature.

  • GitHub repo cabal2nix

    Generate Nix build instructions from a Cabal file (by NixOS)

  • GitHub repo hi

    Generate scaffold for a Haskell project

  • GitHub repo cabal-dev

    A wrapper program around cabal and cabal-install that maintains sandboxed build environments.

  • GitHub repo redo

    djb's redo implementation in Haskell (for Haskell from Scratch video series) (by jekor)

  • OPS

    OPS - Build and Run Open Source Unikernels. Quickly and easily build and deploy open source unikernels in tens of seconds. Deploy in any language to any cloud.

  • GitHub repo fsnotify

    Unified Haskell interface for basic file system notifications

  • GitHub repo path

    Typed filepath (by commercialhaskell)

    Project mention: Code Review Request: StrongPath - Library for strongly type file paths | reddit.com/r/haskell | 2021-07-05

    Hey, thanks so much for taking the time to respond and great job on hpath :)! I was using `path` extensively until we mostly replaced it with `strong-path`, so I know it pretty well, and I was aware of the other two libraries but never used them. However, they all do seem to approach paths in unique way, and I imagine are probably each good for specific set of use cases - in our use case, `strong-path` feels like the best match at the moment. My main drive regarding the features I wanted in `strong-path` was what I felt was missing while using `path`, which we mostly used while writing `Wasp-lang` compiler -> we were using `path` (and now `strong-path`) on many places in the codebase. Therefore I am certainly biased toward our use case, although I also believe it should translate pretty well to what I imagine (emphasis on "imagine" :D!) are common use cases. a) The reason why I added distinction between System/Windows/Posix was exactly to ensure that functions work reliably across both platforms! If you use `Path System` (`type Path' = Path System`) you get file path that uses standard of the OS it is executing on. This is the same thing you get if you use `Path` from `path` library. So if you are working with files on the disk, you will use `Path System` / `Path'` and you can know this code will execute reliably both on Windows and on Unix. I assume this is how `hpath` also works, since there is no mention of posix/windows distinction? On the other hand, if you need to ensure that filepath is always treated as Posix, regardless of OS on which it is executing, you would use `Path Posix`. I had a need for this because we are manipulating javascript import paths and those are always Posix. In `path` library this could now be achieved by importing `Path.Posix` and working directly with it, but I find the way we do it in `strong-path` to be more elegant / integrated. Also, this is working correctly in `path` only since recently -> I wrote a PR that fixed the problems where Path.Posix/Windows was not behaving consistently on different platforms (https://github.com/commercialhaskell/path/pull/167). Additionally, I really like that you can't mix the Posix path with System path or Windows path! While mixing Posix path with System path will work on Unix, since Unix is using Posix, it will not work on Windows, which means we have code that does not work consistently on different platforms. Instead, with `strong-path`, you can be very verbose about what kind of path is your path -> is it using whatever OS is using, or is it something specific (posix/windows), and there is no accidental mixing. I now mostly ended up explaining how this works instead of directly addressing your concerns, but I feel like this should cover them, unless I understood them wrong? b) Interesting! I can understand the idea of not specifying if something is file or directory. But I saw how they are using this File/Dir distinction in `path` and it made a lot of sense to me. From my experience so far, I was never yet in a situation where I didn't know if something was file or dir, and on the other hand, knowing that gives us extra "powers", like for example ensuring that you can't concatenate dir to a file (file > dir). What do you mean by whether something is a file or directory changing during the course of the execution -> could you give me an example? Regarding signaling the intent -> I don't think this library should try to reflect the reality of the world, in the sense that if you get the path to a dir you can be sure that dir exists. Maybe it is yet to be created. But I like the idea of catching the intent in the type -> otherwise I would be just writing it in the comments next to the function declaration. Maintaining invariants -> I can't be sure, but I did write a pretty extensive suite of tests and we use it every day so we caught a lot of problems and I hope not many are left. But I see this just as a "debugging" problem -> the older the library is, the more we will be sure it is handling them well. Parser and what is a valid path -> piggy-backed on `path` mostly so that is something (I am using their parsers mostly), but I agree, this is not a simple problem, I am sure that are some unusual paths which might or might not parse validity as expected. But I believe at the moment it works well for the usual cases and I expect we will handle unusual ones as they come. Thanks for the kind words regarding the documentation :D! I feel it could be made more approachable yet but I haven't managed to figure out how to best do it yet. Do you have any suggestions on ensuring library maintains the variants? I would like to use QuickCheck at some point but haven't gotten to it yet, probably that would be a way to go? Also, do you maybe have any suggestions on how to decrease the duplication in the implementation? Thanks a lot!

  • GitHub repo octopod

    Kubernetes self-service portal

    Project mention: Alternative Approach to Dynamic Environments: Using Octopod | dev.to | 2021-11-01

    In this post, I’d like to tell you how we use dynamic environments (review or preview environments) in our work here at Typeable, what issues we’ve managed to solve, and how and why we use our Octopod solution for these purposes instead of GitLab Dynamic Environments. In case you don’t know what the dynamic environment is, I recommend reading the post by Flant where the author gives a detailed account of the types of dynamic environments, their purpose and applications. The author also looks into this topic using GitLab as an example and provides detailed cases and descriptions. As for us, we use an alternative approach, somewhat different in terms of ideology, and work with review environments in Octopod. Previously we related the history of Octopod creation and the causes that motivated us to create it. We won’t repeat ourselves but will focus on the differences of our approach and the issues we’ve fixed.

  • GitHub repo hslua

    Haskell bindings to Lua, an embeddable scripting language.

  • GitHub repo cabal-bounds

    Set the version bounds of dependencies in a cabal file

  • GitHub repo packdeps

    Web app to track lagging package dependencies.

  • GitHub repo hackage-repo-tool

    Hackage security framework based on TUF (The Update Framework)

  • GitHub repo hackage-diff

    Compare the public API of different versions of a Hackage library

  • GitHub repo prometheus

    Prometheus.io Haskell client. (by bitnomial)

    Project mention: New Ada Folks (<2 years), what made you pick up (or leave) Ada? | reddit.com/r/ada | 2021-09-14

    Haskell has two: https://github.com/fimad/prometheus-haskell and https://github.com/bitnomial/prometheus

  • GitHub repo packunused

    Tool for detecting redundant Cabal package dependencies

  • GitHub repo haddocset

    Generate docset of Dash by Haddock haskell documentation tool

  • GitHub repo cabal-meta

    avoid cabal dependency hell by installing all your cabal dependencies at the same time

  • GitHub repo cblrepo

    Tool to simplify managing a consistent set of Haskell packages for distributions.

  • GitHub repo deptrack-devops

    monorepo for DepTrack

  • GitHub repo cab

    A maintenance command of Haskell cabal packages

  • GitHub repo ltext

    λtext - higher-order file applicator

NOTE: The open source projects on this list are ordered by number of github stars. The number of mentions indicates repo mentiontions in the last 12 Months or since we started tracking (Dec 2020). The latest post mention was on 2022-01-09.

Haskell DevOps related posts


What are some of the best open-source DevOps projects in Haskell? This list will help you:

Project Stars
1 Cabal 1,331
2 aur 1,321
3 hackage-server 332
4 cabal2nix 262
5 hi 202
6 cabal-dev 151
7 redo 142
8 fsnotify 118
9 path 115
10 octopod 97
11 hslua 92
12 cabal-bounds 66
13 packdeps 56
14 hackage-repo-tool 51
15 hackage-diff 50
16 prometheus 50
17 packunused 47
18 haddocset 40
19 cabal-meta 37
20 cblrepo 37
21 deptrack-devops 36
22 cab 36
23 ltext 35
Find remote DevOps jobs at our new job board 99remotejobs.com. There is 1 new remote job listed recently.
Are you hiring? Post a new remote job listing for free.
Static code analysis for 29 languages.
Your projects are multi-language. So is SonarQube analysis. Find Bugs, Vulnerabilities, Security Hotspots, and Code Smells so you can release quality code every time. Get started analyzing your projects today for free.