Hacker News new | ask | show | jobs
by nikolayasdf123 500 days ago
so where does it stop? let's include version of OS on laptop of people who edit code? it is getting ridiculous.

you got to draw a line somewhere.

in my opinion, "if dependency code is not linked nor compiled-into nor copied as a source (e.g. model weights, or other artefacts) then it must not be included into dependency tree of project source code"

that still means, you are free to track versions/hashes/etc. of tools and their dependencies. just do it separately.
3 comments
IshKebab 500 days ago
Ideally it stops at the point where the tools actually affect your project.

Does everyone need to use the same IDE? Obviously not. Same C++ compiler? Ideally yes. (And yes you can do that in some cases, e.g. Bazel and its ilk allow you to vendor compilers.)

link
broken-kebab 500 days ago
It's not that uncommon to have OS version fixed in CI/CD pipelines. E.g. a build process intended to produce artefacts for Apple's Appstore is dependent on XCode, and XCode maybe forced to upgrade in case of MacOS upgrade, and it may break things. So the OS version becomes a line in requirements. It's kinda disappointing, but it's the real state of affairs.
link
nikolayasdf123 500 days ago
how about hardware that software is supposed to run on? that certainly can have effect. let's pin that too into project repo. don't want to continue this thread. but to re-iterate my point, you have to stop somewhere what to pin/version and what to not. I think my criteria is reasonable, but ultimately it is up to you. (so as long whole ecosystem and dependency trees do not become bags of everything, in which case Go here is alright so far. after digging deeper what v1.24 proposing will not cause massive dependency-apocalypsis of tools propagating everywhere and only what you actually use in main is going to be included in go.mod, thanks to module pruning).
link
arccy 500 days ago
yes let's have a meta project that can track the version of my tools "separately", and the version of my repo.

linters, formatters, reproducible codegen should be tracked. their output is deterministic and you want to enforce that in CI in case people forget. the rest doesn't really affect the code (well windows OS and their CRLF do but git has eol attributes to control that).

link
nikolayasdf123 500 days ago
agree it has to be deterministic. my major concern was whether tools dependencies are mixed with actual software they are used to build. hopefully they are not mixed, so that you can have guarantees that everything you see in dependency tree is actually used. because otherwise, there is not much point in the tree (since you can't say if it is used or not).

again, v1.24 seems to be okay here. go mod pruning should keep nodes in tree clear from polluting each other.

link