NixOS
Don't hardcode old channels
It doesn't help people reading the doc, if the example commands are done with EOL channels.
I think this is fine, but only if it was actually confirmed that the docs still work with the updated channel. Did you do that @SuperSandro2000?
It doesn't help people reading the doc, if the example commands are done with EOL channels.
Agreed, but if we don't specify the channel, the user may already have an EOL channel in their NIX_PATH, and this would also fail. Better to be explicit, I think.
To solve the problem of the docs containing EOL'd channels, we could add a CI step to check if instructions like this still work, bumping the channel string to a more recent working channel if not.
If we are hardcoding specific channels then we create the impression that things only work with a specific channel which is not the case. The example commands probably work for any channel in the last 3 years and probably more. We can either keep things slim and simple by removing the explicit channel or create new automations which would make things probably complicated.
I think this is fine, but only if it was actually confirmed that the docs still work with the updated channel.
yeah, the output is obviously different which it was already before because eg the machines arch is different and the channels move so the nix store paths are also constantly changing.
Agreed, but if we don't specify the channel, the user may already have an EOL channel in their NIX_PATH, and this would also fail. Better to be explicit, I think.
There are so many factors why this could fail on end user machines but the high level cross compile functions are in place since many versions and should work on all channels in recent years. The output is anyway not fully reproducible because they depend on the machine they are run on.
If we are hardcoding specific channels then we create the impression that things only work with a specific channel which is not the case. The example commands probably work for any channel in the last 3 years and probably more.
Documentation should be tested just like programming code itself. If we don't, there's the potential for tutorials to not work, which is worse than a working tutorial for older versions.
How about this: Let's be explicit about why those versions are specified by adding a comment like:
This tutorial was tested for the specified Nixpkgs version, but is likely to also work in newer ones.