Top 23 Haskell DevOps Projects
-
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.
-
-
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.
-
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.
-
-
-
cabal-dev
A wrapper program around cabal and cabal-install that maintains sandboxed build environments.
-
-
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.
-
-
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!
-
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.
-
-
-
-
-
-
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
-
-
-
-
-
-
-
Haskell DevOps related posts
- Why doesn't Haskell have a package manager?
- What happened to the Haskell platform?
- cabal / haddock questions / how to generate index for all installed local packages?
- I was trying to make a cargo like tool for c++ but then I thought, "fuck c++"
- Should I remove Haskell, Cabal and start over?
- How can we represent semver
- [Request for review] Short article on Cabal and Stack and difference between them
Index
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 |
Are you hiring? Post a new remote job listing for free.
