2 ms·
No. No, they don't. Specifically, binary dependencies don't belong in a repo and you want to use binary dependencies rather than source dependencies where possi
by jmyeet 3y ago
No. No, they don't. Specifically, binary dependencies don't belong in a repo and you want to use binary dependencies rather than source dependencies where possible.
Once again, we see 20 years of dependency systems that have failed to do what Maven established as the bare minimum. Specifically:
1. Create signed versions of dependencies so you can't rebuild a given release;
2. Allow you to specify a specific version, the latest version or even the latest minor version of a specific major version;
3. Allow you to run internal repos in corporate environments where you might want to publish private libraries; and
4. Version information is nowhere near any source code. Putting github URLs in Go source files is the most egregious example of bad dependency management from a language in recent history.
Every line of source code, whether its yours or third-party comes at a cost. Depending on your toolchain, this may well increase compilation time and required resources.
You want reproducible builds. If you can do that without putting every dependency in a repo then you should. If you can't then you have a bad dependency system.
- shortrounddev2 3y agoI think the only C/C++ package manager that is even close to maven is vcpkg
- jmyeet 3y agoHeader file is both a huge strength and weakness of C/C++ and are really an anachronism now. It's very general purpose text substitution, which is very powerful, but means you have to include .h files to get types, signatures and so on. This kills binary compatibility (specificially, if you're linking to static or shared libraries, you still need a .h file). Even C++ templates aren't really much better and they're still text replacement. More modern languages have taken the use cases for .h files and incorporated them without the general purpose text substitution. Like Rust's macros a superior to #define macros. Type aliases (in various langauges) are better than #define uint32 unsigned int.
- shortrounddev2 3y agoModern C++ also has constexpr, consteval, and using aliases
- __MatrixMan__ 3y agoI definitely agree about URL's in go. Maven comes up all the time as an example of packaging done correctly. It just does JVM stuff though, right? Seems like it's winning at an easier game. Reproducible builds are a hard thing to achieve in the general case. Even something as simple as packaging your files in a tar will blow your determinism. I think retooling for determinism is worth spending time on, but I'm not sure I could convince my boss of that. So far as I'm aware, all dependency systems are bad. Nix is the least bad one I know.
- jmyeet 3y agoSo Java is for JVM languages and binaries. That includes things people probably don't care about anymore (eg Groovy, Clojure, Kotlin, Scala) because they all compile to JVM bytecode so as far as Maven is concerned, they're indistiYou cannguishable. You can include any static assets you want (eg css, js, html files). I honestly haven't looked into that. Putting static assets in a project is relatively straightforward but a JS depdendency? Yeah, that's probably a no go. Or it's really awkward. For hermetic builds, given a blank slate, I'd probably start with Bazel.