3 ms·
Im still looking for a language that will solve my biggest issue: - dependency hell.. Recently had to update unmaintained project by 5 dependency versions hig
by pojzon 3y ago
Im still looking for a language that will solve my biggest issue:
- dependency hell..
Recently had to update unmaintained project by 5 dependency versions higher. It was so painful with GO.
- ParetoOptimal 3y agoI don't use Go a lot anymore, but I sometimes use Nix's buildGoModule: https://nixos.wiki/wiki/Go https://nixos.wiki/wiki/Go Oh wait... You mean because of breaking language changes?
- hu3 3y agoVendoring might help with building old code. It stores a copy of depencies in a directory which you can include in git. https://go.dev/ref/mod#vendoring https://go.dev/ref/mod#vendoring As for upgrading old libraries which might have broken backwards compatibility, I can't offer much.
- bananapub 3y agohow would that help with building old code? is old code often unavailable upstream?
- hu3 3y agoVendoring creates a copy of the dependency files. So no internet connection would be required to build it IF (and that is a big if) the project dependencies were vendored and versioned back then. Interestingly, commiting vendored files is a common point of contention between devs. Some argue that it adds bloat to the project repo. Unless I'm working with TB sized monorepos, I always vendor and commit, because hardware is cheap and my time valuable. I have 10 year old projects that build just fine without internet connection because all deps are commited with the project. As a bonus I get a free diff of every single line that changed when a depency is updated.
- randomdata 3y agoNeeding to change an entire dependency version (let alone four more versions) is a sign of human error. It is unlikely that software will fix a bumbling human. No matter how hard it tries, humans will always find some new way to do something stupid.