@velartrill "please don't use git submodules" ;)
@icedquinn i know it is almost universally hated, but i think vendoring if done right is much better than everything else. maybe throw in a switch to select using vendored or system libs for building.
when packaging submodules are a pain, when developing it isn't much better imho.
it's just my taste though :)
@icedquinn i think it depends on the school of go code. you have the "go guarantee"-never-break-things kind of code where you almost never need any versioning.
then you have the "mOvEfAsTaNdBrEaKtHinGs!!1" kind of code which is just a shit show. usually libraries which do too much and use go in a way it never was supposed to be used (like abusing reflection for everything, etc.).
@icedquinn@blob.cat @bonifartius@qoto.org @velartrill@springbo.cc yeah, the way meson deals with this is pretty okay (and it doesn’t have to involve git submodules). it’s especially useful in situations where you need a custom fork or a patched version of a dependency.
meson is one of the few modern build systems that doesn’t make packaging things a pain, in my experience—when it works. i really like how its development seems to be based on practical experience rather than the kind of overengineering you see everywhere else (in other words, it focuses on solving real problems), but the downside of that is that core functionality breaks pretty often with new releases.
so some software projects always depend on the latest version of meson while others are significantly behind, and you kinda have to hope your distro is packaging one that works with both… i’m sure it’ll stabilize eventually, but right now it’s a bit of a mess.
@velartrill i think it boils down to git having a bad user interface, at least more than submodules being a bad idea.
it's just so unpleasant to use them that i avoid them whenever possible.
if you use something like meson you can actually set it not to use the vendored dependency if one already exists on the system which is comf