raboof has quit [Read error: Connection reset by peer]
raboof has joined #mirage
zmijunkie1 has joined #mirage
zmijunkie has quit [Ping timeout: 240 seconds]
Haudegen has quit [Quit: Bin weg.]
Haudegen has joined #mirage
zmijunkie has joined #mirage
zmijunkie1 has quit [Ping timeout: 252 seconds]
zmijunkie1 has joined #mirage
zmijunkie has quit [Ping timeout: 268 seconds]
jpo has quit [Ping timeout: 260 seconds]
zmijunkie1 has quit [Ping timeout: 252 seconds]
Haudegen has quit [Quit: Bin weg.]
<sterni>
does anybody know what the state of irmin with git 3.4.0 is? or if there are any plans?
<dinosaure>
a release will be done soon :)
<sterni>
very nice
zmijunkie has joined #mirage
zmijunkie1 has joined #mirage
zmijunkie1 has quit [Client Quit]
zmijunkie1 has joined #mirage
zmijunkie has quit [Ping timeout: 265 seconds]
Haudegen has joined #mirage
zmijunkie1 has quit [Quit: Leaving.]
zmijunkie has joined #mirage
<hannes>
sterni: I'm with you, waiting for such an irmin release as well ;)
<sterni>
I started with preparing a PR updating cohttp* and conduit* to 4.0.0 (2.3.0) for nixpkgs like a month ago and now I've accumulated 25 package updates as the whole mirage universe is slowly reflecting the breaking changes :)
<sterni>
although I think mostly x509 and tls caused the most breakage in reverse dependencies
<sterni>
but the irmin update should mean that everything builds again and we can merge so not too bad all in all
<sterni>
and tbf this is pretty quick all in all considering the number of different projects
<hannes>
sterni: yes I do break APIs. sorry about it.
<hannes>
sometimes on a daily basis. likely not in the upcoming months.
<sterni>
well I mean, that's what you have types for right :p
<hannes>
there's a reason why I keep on using 0.something - it's an unstable API
<sterni>
this is mostly a shortcoming of how we package ocaml packages at the moment that is by manual effort
<hannes>
indeed, and if the API is wrong (or bad) it should be changed
<hannes>
sterni: then maybe we should talk about automating that? :)
<sterni>
yeah I've had ideas towards that, but I haven't been motivated to work on it yet
<avsm[m]>
sterni: have you tried using opam2nix to generate the nixpkgs? the opam metadata has the constraints to keep it consistent among all the updates
<sterni>
avsm[m]: I need to look into it in more detail, but I suspect that opam2nix is not really designed to generate a blessed package set of ocaml packages
<sterni>
but yeah something along those lines is what we'll need to do: throw the opam solver at a list of packages and get our set that way
<sterni>
with the way opam is managed you can at least trust the constraints for the most part from my impression which is probably a huge help when you try to achieve something like that
<hannes>
sterni: in nixOS you package one version of each library? so in contrast to opam-repository, you don't have uri.4.0.0 and uri.4.1.0 and uri.4.2.0 ?
<sterni>
hannes: yeah we mostly have one library only, sometimes more if we have some dependency issues
<sterni>
if we automatically generate stuff we could probably justify having multiple versions
<sterni>
you just have to watch the size of your package set unfortunately
<hannes>
why? what are the limitations?
<sterni>
the whole expression language side of nix is not really optimized unfortunately
<sterni>
we have a file in nixpkgs which contains at most 2 versions of every package on hackage
<sterni>
and it takes ~1s to *just* parse it
<sterni>
although I think you can kind of cheat your way past this if you use JSON exclusively to specify a large heap of meta data
<sterni>
since the JSON parser of nix is pretty fast
<sterni>
but all in all this probably warrants some experimentation and incremental steps
<hannes>
ok, I was thinking about other issues such as number of files / symlinks in a directory, etc.
<sterni>
haskell ended up with an automated infrastructure some of the maintainers are a bit unhappy with
<sterni>
so I think it's wise to experiment a bit to find something that actually works with ocaml
<hannes>
honestly I'm in favour to have a single version of each library, and work hard on updating all dependencies & reverse dependencies
<sterni>
yeah it is also less work most likely
<sterni>
since there is always some amount of manual intervention necessary
<hannes>
since (at least my experience) once opam package foo in version 3.x is released, the foo 2.y series isn't getting much maintenance
<hannes>
and as you mentioned, usually type-driven refactoring / upgrades works nicely
<sterni>
also you run into trouble with multiple versions in a package set inevitable because with ocaml you depend partially on dependencies of dependencies (if parts of their interface are reexposed or referenced) so you eventually run into issues with different dependencies depending on the same other library, but different versions respectively
<sterni>
but the “blessed package set” seems attainable, you'll have a bit of delay between the newest version coming out and being able to upgrade to it in some cases, but that's not really a problem
<sterni>
if you depend on bleeding edge stuff you won't be using nixpkgs anyways probably
<hannes>
sterni: yes indeed. so, AFAIU nixOS does not attempt to package all opam packages? what are the root packages that are being packaged (and how is this list grown)?
<hannes>
I understand that some applications (e.g. jackline) are part of that root package set. but what else (does it even exist explicitly?)
<sterni>
it's a bit messy
<sterni>
only a few things, but some stuff depends on extremely old ocaml versions
<sterni>
of the top of my head: sks-keyserver, stog, dune-release, jackline, google-drive-ocamlfuse
<sterni>
I wasn't around when the infrastructure was conceived, but I suspect also a big part was supporting Coq
<sterni>
but we have some stuff as well which is not necessary to package anything
<sterni>
for example nothing really depends on irmin
<hannes>
sterni: my experience is that having such an explicit list is very useful, esp. when you're at a point that upstream changes some dependencies and you're not sure whether that packaged library is still used by anyone
<hannes>
unison is likely a packaged ocaml project as well ;)
<sterni>
yeah, I really need to make a sweep and clean some of that stuff up as well
<sterni>
yes!
<sterni>
I mean all OCaml versions before 4.06 have CVEs pretty much and we still have things using those versions :|
<hannes>
I've run into walls several times in respect to "what OCaml libraries are packaged in FreeBSD", and looking into git history of ports doesn't lead to success..
<hannes>
sterni: what (apart from sks) requires such old OCaml versions?
<hannes>
^^ having this explicit set/list of "ocaml packages to integrate" would also help you to use opam solver to figure out which versions to package :)
<sterni>
at least it seems we can throw away 4.00 and 4.03 today already
<sterni>
hannes: yeah my plan was to start with a list of packages we need and throwing a sat solver at it and generate a package set from that for starters
<sterni>
with a limited scope at first instead of packaging all of opam right away
<hannes>
yes, wise way forward. in opam-repository there's at least an mldonkey with ocaml < 4.10.0 support (anything < 4.06.0 is just not worth it)
<Armael>
it sounds like you could start by building an opam switch with the packages that you want installed in it, and then use the list of total installed packages as what to package in nix
<Armael>
thus you'd get the opam solver to do the job for you
<Armael>
also you could use that switch for upgrades, ie let opam do the upgrade, relying on the solver to minimize changes wrt existing packages
<avsm[m]>
you can actually opam-0install-solver to very easily script that without involving opam at all. Just pick a set of root packages (the binaries) that you want compiling, and it'll give you a compatible subset within a second or so
<avsm[m]>
I'm not in favour of minimising upgrades/downgrades anymore. The solving pain involved in that isn't quite worth the reward for package managers, I think. Just do a one-shot solve every time and package up the result.
<sterni>
I mean I guess you want to avoid downgrades, but minimizing changes in package versions is not interesting for us at all
<sterni>
I was also meaning to look into finding the opam solver which can be separated most easily from the rest
<sterni>
since it seemed pretty simple as in you give it a command line of packages with optional constraints and it gives you a solution if possible
<sterni>
I was looking at the 0install solver, but also considering the predecessor of the opam internal solver
<hannes>
after reading the very nice blog article on floatarray https://www.lexifi.com/blog/ocaml/floatarray-migration/# - I'm actually curious what compiler configuration options should be used? it looks to me for the future, the no-flat-float-array, no-naked-pointers, -flambda would be sensible for every MirageOS unikernel!?
Haudegen has quit [Quit: No Ping reply in 180 seconds.]