Thanks for the motivation and context, @lefessan. I find the additional info helpful, especially pointers on how I might use the tool without committing to another level of configuration.
When I’d first skimmed the docs, it looked to me like the new config didn’t add anything that wasn’t already in
dune-project files (or was supported by them), but after reading further (thanks to your reply), I see it also configures and manages other things like a sphinx configuration and CI configuration.
we want to have all the projet configuration in one place, and all other files generated from it. Such a unique configuration file does not yet exist, so we had to create it.
I suppose this depends on what you consider to be the bounds of a project configuration! iirc, Cargo also doesn’t configure a github-centric CI or an external documentation engine. I believe the configurations available via dune-project are roughly on par with what cargo files offer. So, it seems to me, the need for a new configuration format follows from the expansion of what is considered as part of the project configuration. Personally, I’m not sure whether I want those things in my package configuration (or if I did, I think I’d probably opt for a more total solution, like nix), however, I can definitely see the value added here!
While I’m still unsure whether drom is well suited for my workflow, I definitely appreciate the work, and I look forward to following its development
I thought I might share some notions I’ve had re: the success of cargo. I believe a lot of cargo’s success follows from these two features:
- The total integration of package management and build system (i.e., between deployment and delivery) which comes from using a single tool for both. I’m not sure if the tight coupling is necessarily an overall good thing in the long run, but it definitely has some advantages. Obviously, one of drom’s aims is to help fill in this gap.
- Cargo’s very narrow focus in terms of project management, and the simplicity of the tool that this entails. E.g., cargo has no support for different templates, and an RFC to add support for them seems to have resulted in a resolution to improve the documentation instead. This simplicity lowers the learning curve, and provides devs a small and digestible common basis to work from. My concern with elaborate configs and project initialization is that it might end up front loading technical debt on new projects (or generally encourage a boiler-plate central development style, as we see common in JS and other webdev communities). However, this is likely particular to my POV and proclivities.