4 ms·

> building a little HTTP server opam install cohttp > command-line tool opam install cmdliner > Go has a great batteries-included standard library.

> building a little HTTP server opam install cohttp > command-line tool opam install cmdliner > Go has a great batteries-included standard library. OCaml doesn't, but there are good stdlib replacements, and its package manager is really nice.

mjt0229 12y ago
Thanks for the pointer to `cmdliner`. I've built a handful of command line tools using Command from the Core library (as described by Real World OCaml [1]), but I always have to have the book open to use it. This looks very nice and it looks like it might fix an annoyance I have with Core's `Command`, which is that it won't parse flags without spaces (i.e., `-r2` failes to parse as equivalent to `-r 2`). [1] https://realworldocaml.org/v1/en/html/command-line-parsing.html https://realworldocaml.org/v1/en/html/command-line-parsing.h...
- ufo 12y ago
  cmdliner's applicative-functor interface has a bit of a learning curve but the end result is some really clean programs. It can also generate manpages!
amirmc 12y ago
If anyone would like to do things with Cmdliner, then there are few libs that would be great to have as stand-alone executables (it's part of the MirageOS Pioneer Projects) [1]. https://github.com/mirage/mirage-www/wiki/Pioneer-Projects#command-line-utilities https://github.com/mirage/mirage-www/wiki/Pioneer-Projects#c...
- zem 12y ago
  nice list! was this always on the mirageos site? i remember spending some time poking around specifically looking for something like this, and coming up blank. (suggestion: link to it from the "contributing to mirage" page as well)
AceJohnny2 12y ago
I tried to use Opam on Debian Unstable a few months ago. It was 1.1.0. When requested to install a second package with overlapping dependencies as a previous package, it would try reinstalling all dependencies, including previously installed ones, and would fail. That is, in my book, an epic fail for a package manager, let alone a supposedly >1.0 version (if that even means anything today). I'm still annoyed about that. Searching online found recommendations to get the latest version from Github. 1.2.0 has since been released and included in Debian. I keep meaning to give it another go, but I must admit being wary after that first experience.
- e12e 12y ago
  I agree, opam was rough a while ago - not sure about now. Fwiw both erlang and haskell have also been rather painful on Debian. As far as I know, ruby still is, to a certain extent. Go is sort of in between by virtue of building mostly stand-alone binaries, if you can get the program to compile. Haskell's cabal has gotten better; it's still easier to run xmonad/mobar from Debian packages, but at least cabal with packages/cache in ~/.cabal kinda-sorta works. It seems the path towards package managers that both work well and work well with stable/distro packages is long, ardous and filled with repeating the mistakes of others. Npm seems to have learned a bit from python - if you stay away from -g(lobal), it tends to mostly just work (not sure about c/c++ dependencies - for better or worse a lot of npm packages are mostly pure js). Python with virtualenv works very well, except for a few hairy c-heavy packages (pygame, sci-py) - but running "sudo pip install ..." is a recipe for disaster (or a mongrel, unpatchable mess). Keep to virtualenvs and you can stay mostly sane (or use the isolation provided by buildout -- preferably in concert with virtualenv).
  - AceJohnny2 12y ago
    I'm not sure we're talking about the same thing. Are you lamenting the difficult interface between distro package managers and language package managers? Or lamenting that language package managers haven't learned the lessons of previous package managers, distro and language alike? I was lamenting that Opam 1.1 wasn't dealing with a trivial package installation situation. I mentioned Debian to indicate that was the source of the version I was using, implying that there may have already been a newer version out there that I could've been using, but then explicitly saying that 1.1 should've dealt with the situation in the first place. FWIW, I definitely agree with the terrible situation of language package managers in general. I use Python sporadically, and I'm always scared of running pip. Virtualenv I'm very unhappy about because, while it definitely fulfills it's task marvelously, I think it shouldn't even have to exist in the first place! Why doesn't core Python deal with the problem itself, searching for dependencies in the main script's subdirs, the user's libdir, and lastly the system libdir? Admittedly, I don't know the intricacies of the Python ecosystem that prevent that.

mjt0229 12y ago

Thanks for the pointer to `cmdliner`. I've built a handful of command line tools using Command from the Core library (as described by Real World OCaml [1]), but I always have to have the book open to use it. This looks very nice and it looks like it might fix an annoyance I have with Core's `Command`, which is that it won't parse flags without spaces (i.e., `-r2` failes to parse as equivalent to `-r 2`). [1] https://realworldocaml.org/v1/en/html/command-line-parsing.html https://realworldocaml.org/v1/en/html/command-line-parsing.h...

ufo 12y ago
cmdliner's applicative-functor interface has a bit of a learning curve but the end result is some really clean programs. It can also generate manpages!

amirmc 12y ago

If anyone would like to do things with Cmdliner, then there are few libs that would be great to have as stand-alone executables (it's part of the MirageOS Pioneer Projects) [1]. https://github.com/mirage/mirage-www/wiki/Pioneer-Projects#command-line-utilities https://github.com/mirage/mirage-www/wiki/Pioneer-Projects#c...

zem 12y ago
nice list! was this always on the mirageos site? i remember spending some time poking around specifically looking for something like this, and coming up blank. (suggestion: link to it from the "contributing to mirage" page as well)

AceJohnny2 12y ago

I tried to use Opam on Debian Unstable a few months ago. It was 1.1.0. When requested to install a second package with overlapping dependencies as a previous package, it would try reinstalling all dependencies, including previously installed ones, and would fail. That is, in my book, an epic fail for a package manager, let alone a supposedly >1.0 version (if that even means anything today). I'm still annoyed about that. Searching online found recommendations to get the latest version from Github. 1.2.0 has since been released and included in Debian. I keep meaning to give it another go, but I must admit being wary after that first experience.

e12e 12y ago
I agree, opam was rough a while ago - not sure about now. Fwiw both erlang and haskell have also been rather painful on Debian. As far as I know, ruby still is, to a certain extent. Go is sort of in between by virtue of building mostly stand-alone binaries, if you can get the program to compile. Haskell's cabal has gotten better; it's still easier to run xmonad/mobar from Debian packages, but at least cabal with packages/cache in ~/.cabal kinda-sorta works. It seems the path towards package managers that both work well and work well with stable/distro packages is long, ardous and filled with repeating the mistakes of others. Npm seems to have learned a bit from python - if you stay away from -g(lobal), it tends to mostly just work (not sure about c/c++ dependencies - for better or worse a lot of npm packages are mostly pure js). Python with virtualenv works very well, except for a few hairy c-heavy packages (pygame, sci-py) - but running "sudo pip install ..." is a recipe for disaster (or a mongrel, unpatchable mess). Keep to virtualenvs and you can stay mostly sane (or use the isolation provided by buildout -- preferably in concert with virtualenv).
- AceJohnny2 12y ago
  I'm not sure we're talking about the same thing. Are you lamenting the difficult interface between distro package managers and language package managers? Or lamenting that language package managers haven't learned the lessons of previous package managers, distro and language alike? I was lamenting that Opam 1.1 wasn't dealing with a trivial package installation situation. I mentioned Debian to indicate that was the source of the version I was using, implying that there may have already been a newer version out there that I could've been using, but then explicitly saying that 1.1 should've dealt with the situation in the first place. FWIW, I definitely agree with the terrible situation of language package managers in general. I use Python sporadically, and I'm always scared of running pip. Virtualenv I'm very unhappy about because, while it definitely fulfills it's task marvelously, I think it shouldn't even have to exist in the first place! Why doesn't core Python deal with the problem itself, searching for dependencies in the main script's subdirs, the user's libdir, and lastly the system libdir? Admittedly, I don't know the intricacies of the Python ecosystem that prevent that.