I’m a little out of the loop on this–can someone give me a pointer to the work being done on the dune opam integration i.e. ‘Cargoization’ project? E.g. are there some design documents, issues, etc.?
EDIT: found the RFC [RFC] Dune Package Management · Issue #7680 · ocaml/dune · GitHub
The OCaml Platform monthly newsletter by @tmattio usually provides updates on the progress of that specific project: Search results for 'Platform newsletter order:latest_topic' - OCaml
Is this about making one tool out of two?
Sounds like a violation of the Unix philosophy (do one thing and do it well).
By that argument, Mirage is against the Unix philosophy too because it bundles the kernel with the application. I don’t think the Unix designers ever wanted blind adherence to the ‘philosophy’; there are different contexts with pros and cons for all tech decisions.
The unix philosophy is hilarious sometimes, because it all depends on
what “one thing” means.
Cargo does one thing and does it well: it builds your project. With a
single command typically. So unix!
There are many things which violate the Unix philosophy; including the leading OS on desktop computers.
Many people have bad taste, but that’s no reason to be so inclined.
Fwiw, I don’t feel that dissing other’s substantive work or chosen toolsets on the grounds of taste is very helpful in this kind of discussion.
There are surely substantive technical discussions to be had, but slinging mud at dead horses (to mix metaphors) seems unproductive.
I don’t feel like these are antagonist goals actually. We can (and IMO should) preserve the different tools, which should have their autonomy, with the many advantages of the Unix philosophy: if you know what you’re doing you can swap out one of them, responsibilities are clearly delimited, etc.
On the other hand, it doesn’t prevent us from having one of these tool act as a frontend/driver for the others, so that new users or users that don’t care about these details can have a seamless experience.
Personally I will probably still want to deploy my own Opam repositories and hack around with the tools, but when quickly testing another project or when onboarding a member of my team I certainly don’t mind only needing to type dune.
I think it’s worth emphasising that Dune’s package management isn’t driving the opam tool, rather it’s consuming the same data as the opam tool (in a similar, but rather larger, way to how Dune consumes META files, but doesn’t drive ocamlfind).
The difference should not be noticeable to the user, other than that it’s faster - I believe it’s still the case that switching between Dune’s package management and going back to an opam switch is as simple to the user as switching between having a copy of the a package repo in your local workspace (in vendor/ or whatever) and then deleting it to go back to using the opam package from your switch.