Hacker News Reader

Comment by vbezhenar | Hacker News Reader

Here's my 2 cents how build system should work. I'm not sure that any build system works like that... But anyway.

All dependencies sources must be included with project sources. When you check out repository, you should have everything necessary for building the project. Sources should be in their original form, so you could fix anything quickly.

Libraries builds must be reproducible. Output artifacts hashes must be provided along with sources. It means that one should be able to download pre-built artifacts from the Internet. But if they're not available, that should not be an issue.

Ideally whole build environment should be part of project, something like docker container. So your compiler and necessary build tools are fixed as well.

Of course there should be some tooling to check for new dependencies versions, print changelogs if available, etc. But it must not be automatic.

View on HN

Check out Nix (https://nixos.org) which is designed around exactly this model.

It works by putting the package hash into the path that you access the package by and hardcoding the path in all dependencies. This way every package has a hardcoded version as a dependency, however updating dependencies, even indirect ones is doable.

However, the thing that’s lacking in typical use is granular updating of dependencies. By default you update sources independently, however the biggest source (nixpkgs) is a monorepo providing most major software. You can always figure out which version things have updated to and manually audit and pin the versions you don’t want and there is some tooling (not in Nix itself, but a 3rd party package) that does this.

> All dependencies sources must be included with project sources.

This sounds great for applications. But for libraries, you'll likely end up with the diamond dependency problem: an application uses two libraries, and each library uses their own copy of a third library.

In Java you have to decide which version application is going to use in the end. Maven decides that somewhat randomly. Gradle have some tricky algorithms to determine which version is highest one. You can put two versions of the same library on the classpath anyway, at least without some tricks with classloaders which are not used for ordinary applications.

So basically with Java you would need to flatten all dependencies and resolve version conflicts in some way (sometimes you must downgrade one library or even declare that some libraries are not compatible with each other, but that's a rare occasion).

AFAIK npm uses hierarchical dependencies, so few libraries with a different versions are not a problem at all (at least if those libraries are good citizens and don't pollute global namespace or use it carefully).

Maven isn't random - it is described at https://maven.apache.org/guides/introduction/introduction-to...

> Dependency mediation - this determines what version of an artifact will be chosen when multiple versions are encountered as dependencies. Maven picks the "nearest definition". That is, it uses the version of the closest dependency to your project in the tree of dependencies. You can always guarantee a version by declaring it explicitly in your project's POM. Note that if two dependency versions are at the same depth in the dependency tree, the first declaration wins.

Well, in practice that turns out pretty random IMO. Nearest definition is meaningless. Order of declaration of dependencies is meaningless as well. It's not random in the sense that it does not change between builds if pom.xml not changed, but this deterministic algorithm does not make any sense, at least to me.

Reply on news.ycombinator.com