That's exactly my experience with Hugo and why I stopped using it.

What do you use now?

I found embedding some React into a Hugo site involved a few workarounds…

I will be trying Astro for the next site.

I switched to Antora but recently shut down my homepage after more than 20 years.

The out-of-context quotes by Tony Hoare are at least questionable.

The not optimising, that's making it insecure and bloated.

Indeed, it would be useful to know why each of these points are not enabled by default (including a huge amount of non-free and less verified software is an obvious one). In particular the `sbin` one I assumed because it's stuff you'd only use as root and they already have it on their path. E.g. `reboot` might say "not found" but `sudo reboot` will work.

Exactly this.

"use opam" is always the answer but in reality its the worst package manager ever. I've never seen so many packages fail to install, so many broken dependencies and miscompilations that resulted in segfaults due to wrong dependencies. I just gave up with Ocaml due to the crappy ecosystem, although I could have lived with the other idiosyncrasies.

And even if you do get opam working for a project, it's not at all reproducible and will just randomly break at some point in the future. For instance, I had this in a Dockerfile for one project:

  RUN eval $(opam env) && opam install --yes dune=3.7.0

One day the build just randomly broke. Had to replace it with this:

  RUN eval $(opam env) && opam install --yes dune=3.19.1

Not a big change, but the fact that this happens at all is just another part of building with OCaml feeling like building on a foundation of sand. Modern languages have at least learned how to make things reproducible with e.g. lockfiles, but OCaml has not.

Use "opam lock" and "opam pin". Additionally, Dune's lockdir feature uses opam's solver internally to generate a lock directory containing ".opam.locked" files for every dependency. This is Dune's way of having fully reproducible builds without relying on opam's switch state alone.

Additionally, see: https://dune.readthedocs.io/en/stable/tutorials/dune-package....

No, the problem is that dune=3.7.0 got removed from the registry entirely.

Yes, the opam repository has recently been working on an archival policy to reduce the size of the checkout and hopefully ease pressure on the dependency resolver by pruning 'obviously' wrong choices. However, the heuristic they chose seems to have mainly assumed that the things in the repository are libraries, and used dependencies for tracking usages. For executables like dune, this is obviously the wrong idea, and I think they're still deciding how to proceed while adding back most versions

It is still there according to "opam show dune --all-versions", so no, it has not been removed.

Anyways, what you could do is:

  opam pin add dune 3.7.0
  opam install dune

Alternatively, you can use the tarball directly:

  opam pin add dune https://github.com/ocaml/dune/releases/download/3.7.0/dune-3.7.0.tbz

I tried going back to change my Dockerfile to see if that would work, and it did not:

  RUN eval $(opam env) && opam pin add dune 3.7.0 && opam install --yes dune

Similar error to before:

  [ERROR] Package dune has no known version 3.7.0 in the repositories

You're right that I could change it to grab directly from GitHub, but at that point I can also just change it to a different version of Dune, as I said above. None of this negates my original point.

What if you do "opam update" before?

I already do: https://github.com/gradbench/gradbench/blob/0276272d0df5be19...

And the CI build doesn't use Docker caching, so no shenanigans there.

Actually, I did an "opam update" (after my comment that stated there was "3.7.0") and "opam show dune --all-versions" no longer shows "3.7.0". :|

It shows:

  all-versions         1.6.3  1.9.3  1.11.4  2.3.0  2.4.0  2.5.1  2.6.1  2.7.1
                       2.9.3  3.5.0  3.6.2  3.10.0  3.12.1  3.12.2  3.15.3
                       3.17.2  3.18.2  3.19.0  3.19.1

You are right! So I suppose it is either 3.6.2 or 3.10.0. Can you use either of these versions?

Your alternative really is:

  $ opam pin add dune https://github.com/ocaml/dune/releases/download/3.7.0/dune-3.7.0.tbz

If you really must need "3.7.0".

Just FWIW, maybe it might work the way you wanted it to if you do not update the registry; worth a try. It should be able to fetch the correct tarball.

There is a lot of work on Dune Package Management that will fix some legacy issues related to OPAM, https://dune.readthedocs.io/en/stable/tutorials/dune-package... !! Stay tuned!

Dune is not a dependency manager, it is a build tool. Opam is the dependency manager. By default, Dune doesn't fetch dependencies, opam does that. That said, Dune does use opam, yeah.

And the next milestone of Dune is to become an alternative package manager via Dune package Management, using a store in a "nixish" way.

I suppose it is still going to use opam internally, right?

No, it is doing its own package management implementation.

So dune is going to replace opam? Where can I read more about this if so?

Package description, but it use its own engine.

I have never had issues and been writing OCaml and using opam for years.

Can you be more specific?

(Why the down-vote? He does need to be specific, right? Additionally, my experiences are somehow invalid?)

I mean, it's quite clunky, but on Linux or WSL I've never had the broken experience you talk about. Could you share your setup? Was this maybe on bare macOS or Windows, in which case I totally believe it because they've been neglected?

No, just Linux or inside Docker (on Linux).

Question as a parent: kids do need constant snacking now? I know some kids who do but they are overweight.

I'd recommend "Ultra processed people" be van Tulleken. He references the relevant studies, doesn't try to convince you to change your diet but gives enough food for thought. ;)

but that food for thought has been processed by others already...

Horse tastes fine and I'd prefer it over UPF crap all the time.

The _real_ scandal in that horse meat thing wasn't so much the fact that it was horse, but the fact that, clearly, the traceability system had utterly broken down.

> The article is abut "ultra-processed" food.

I was responding to a comment that said “highly processed”.

Regardless, the mozzarella and tomato sauce purchased from the local store inside of a package or jar with long shelf life is likely to be ultra-processed.

Luckily, Mozzarella here only contains milk, salt, bacteria and rennet and many tomato sauces are free from UPF ingredients.

You can find the same here.

But discussing the best-case scenario where all ingredients are sourced perfectly is missing the point. When someone says pizza or hamburger they’re not talking about the theoretically optimal perfectly produced pizza to minimize processed food content, they’re talking about what people are really buying and eating.

> When someone says pizza or hamburger they’re not talking about the theoretically optimal perfectly produced pizza

I don't know what "garbawarb" meant with "basic pizza", a frozen one or pizza in general? I just argued that flour, mozzarella and simple tomato sauce are not the best examples for UPF.

"Simple" sugar doesn't make it ultra processed, it's the modified starch, glucose syrup, emulsifiers, ...

Sure, that's what I meant.