Part of the reason that pds and hll were created is to experiment with the belief that builds, packaging, and dependency management should be separate. Builds systems such as Maven and rebar conflate these operations into one tool. It is the belief of the author that combining this functionality into one tool costs more than the value it offers.

The main argument for combining all of this functionality is that it produces a streamlined experience for the user. The system can know when to rebuild targets, when to download them, and from where to download them. The approach that Maven and rebar take is a single tool which understands the input files and provides hooks to perform other operations. Because the possible operations are infinite, the interface for these tools is either quite large, such as in Maven, or small but incomplete, such as in rebar (at least in rebar2, I have not used rebar3). One is also limited to writing plugins in the language these tools are implemented in rather than the one with which the user feels more comfortable. The input files are generally not designed to be consumed by other tools either as the file schemas are poorly defined or the file formats are not easy to parse. In the case of Maven, this is an XML file which requires complex parsing and in the case of rebar the configuration is Erlang terms.

The approach that pds has taken is to define the file format and schema as the public interface. With that, tools can be written around the input files to perform operations above and beyond the existing tooling. hll, itself, is an example of this. hll was not part of the original idea when implementing pds but once pds was building projects we made some packages for them by hand and realized that it would be nicer if that were automated. We added hll.conf with the metadata needed to generate a package and the hll command reads that and the pds.conf whose schema it can depend on. Similarly, other tools can depend on the schema of hll.conf . With this we've avoided having to add complexities to pds, such as a plugin system, in order to support new use-cases. pds can focus on just being good at building software and hll on generating OPAM packages. An additional benefit is that adding new functionality, such as generating packages for ones favorite package manager doesn't require reading through an existing code base and understanding how building works or how OPAM package generation works. Both of which are likely irrelevant to making the new feature.

In my opinion, this experiment has been a success. pds and hll have fulfilled my needs and I've converted all of my existing projects over to them without issue. While it's hard to say, as I understand these tools inside and out, I believe them to be simpler to use. The line count (just using wc -l ) of these tools combined is 1108 lines, making the worst case of having to read the code to understand them quite manageable. For comparison, the line count of all the Java source files in Maven is 128,416 lines. The comparison is not entirely fair as that includes tests and Maven does more than pds and hll but even so, that is two orders of magnitude more lines of code.

Like any pattern, it's not applicable everywhere and it's up to the judgment of the user as to where to use it. But when making a new piece of code, consider if maybe more of it should be pushed down into configuration that can be shared.