thanks!

Any reason to remove 1.13 when it is still supported?

In addition to remove a still supported version that might be used downstream, this change does not even fits CONTRIBUTING.md as it mentions in the pull request description. Yikes.

nixpkgs doesn't need to include all versions of everything. Go 1.13 should still be available in the nixos-20.03 channel.

There are packages, like #86957, which, although they build, won't work on 1.14 (just yet). We should give the developers time to adapt to these changes as long as 1.13 is supported. There's no point in having broken packages in nixpkgs.

From https://golang.org/doc/devel/release.html:
Each major Go release is supported until there are two newer major releases.

From https://golang.org/project/:
Go 1.14 (February 2020)
Go 1.13 (September 2019)

Go release cycle is 6 months so that gives us plenty of time for dropping the support sometime before 20.09, but it was rather hasty to remove it so early before EOS.

I'll take a look at that pr tonight - if something doesn't work on go 1.14
we should ensure that we have an updated bug report to go :). Do you happen
to know how to repro the failure? Just run it?

@c00w yes, just run it, but you'd have to provide configuration files and a backend to run it with. I'm trying to push this forward so we could implement it a module, package was just the first, intermediary, step.

FYI this is how the incompatibility "bug" looks like:

blockbook -blockchaincfg=/root/blockchaincfg.json -datadir=/opt/blockbook/data/db -sync -internal=:9030 -public=:9130 -explorer= -dbcache=1073741824

E0505 21:01:46.455691    1140 blockbook.go:369] rpc: json: invalid number literal, trying to unmarshal "\"/Satoshi:0.19.0.1/\"" into Number Retrying...

The problem, with a lengthy discussion, is described here: golang/go#37308

Historically, we haven't done a good job of keeping up to date on go (we
migrated off 1.12 last week, 3 months after it was deprecated), so I'm
trying to move everything forward onto the latest release as much as
possible.

I understand and totally agree. You did a great job cleaning up 1.12 since it reached EOS but removing 1.13 seems to be a bit rushed.

If we need to add go 1.13 back it's a pretty simple diff, but we should
only do it if it's actually an upstream bug :).

I've already reported it to blockook upstream (go is also aware of this, hence the issue earlier in the comment), they are aware of it and said they'll make sure the app is rewritten before 1.13 reaches EOS but until then, I'd like to keep the package functional - for others and also so we'd be able to work on module implementation.

Re: right speed - I think it's good to not keep old versions of software
around if they're not needed for a build purpose. If we need them to build
we need them to build, but if we don't it's not worth having Hydra build it
even if it is technically within the support window.

Right, and I admire your determination, but maybe it would be better not to waste your precious time on something that will eventually get fixed in a few week's time. And what if there are other packages (which we do not know of yet) affected by this change?

Right, and I admire your determination, but maybe it would be better not to waste your precious time on something that will eventually get fixed in a few week's time

Wait - I thought you were registering a complaint. If you're just looking for how to patch go1.13 back in, just rebase on master, then running

git revert --edit 3e0aa4af2da4e4010cd9011aaa125fed7ca220e6

should add it back for you, just drop the terraform fixes and everything should be g2g.

And what if there are other packages (which we do not know of yet) affected by this change?

Thankfully grep works pretty well to verify this :)

Sent patch + commented on the PR.

I didn't expect Go 1.14 to have as many regressions. Usually Go is pretty good about keeping back-compat compared to other languages. For other languages, we usually keep a few versions around as well.

@c00w can you link to the revert PR?

Right, and I admire your determination, but maybe it would be better not to waste your precious time on something that will eventually get fixed in a few week's time

Wait - I thought you were registering a complaint. If you're just looking for how to patch go1.13 back in, just rebase on master, then running

git revert --edit 3e0aa4af2da4e4010cd9011aaa125fed7ca220e6

should add it back for you, just drop the terraform fixes and everything should be g2g.

I was :) - I'd like to have this working in master, too. But that would mean reintroducing go1.13 i.e. reverting this MR.

And what if there are other packages (which we do not know of yet) affected by this change?

Thankfully grep works pretty well to verify this :)

There could be packages that do build but don't work (same as it's with blockbook).

I was :) - I'd like to have this working in master, too. But that would mean reintroducing go1.13 i.e. reverting this MR.

I was what? I have 0 objections to adding go1.13 back in if we need it for packages - let me know if that revert command doesn't work. I feel strongly if we don't need it to build something we shouldn't keep it around.

There could be packages that do build but don't work (same as it's with blockbook).

Yeah but we're only humans and robots. There is a limited amount of verification the current tooling can do - everything builds is a pretty good sign, everything builds, every binary executes + all configured tests pass is the best we can do (and is I believe what happened in this PR) :). If we refuse to change anything in the build system because we fear we might cause undetectable regression in runtime behaviour, then we'd never update anything.

@c00w can you link to the revert PR?

Sorry? I don't follow what you're asking?

@c00w I've managed to convince upstream to fix it on their end, so disregard my complaint :). Thanks for your help.

We do keep a go_1_12 in pkgs/top-level/aliases.nix which returns a throw "go_1_12 has been removed"; - if we decide to keep go_1_13 removed, it should probably still be in there for consistency.

re-added Go 1.13. Sorry for the delay.

I did a partial revert, just to re-add Go 1.13 and left the accompanying fixed in the tree.