Deprecation of buildGoPackage

[katexochen]

Issue description

Go modules, released 6y ago, are now widely adopted in the ecosystem. Most remaining (~30) packages in nixpkgs using buildGoPackage weren't touched in years. I think most of these can be easily migrated to modules by adding the mod file downstream (or should be removed anyway as they are/their upstream is unmaintained).

Pase 1: Migrate remaining packages using buildGoPackage

• allmark - allmark: migrate to buildGoModule #318220
• assetfinder - assetfinder: migrate to buildGoModule #318089
• aws-assume-role - aws-assume-role: migrate to buildGoModule #318091
• aws-env - aws-env: drop #318967
• consul-alerts - consul-alerts: migrate to buildGoModule #318257
• containerpilot - containerpilot: remove #318571
• coyim - coyim: migrate to buildGoModule #318581
• dep2nix - dep2nix: remove #318607
• (docker-)distribution - docker-distribution: 2.8.3 -> 3.0.0-alpha.1 #280911
• docker - docker: migrate to buildGoModule #318922
• docopts - docopts: migrate to buildGoModule #318612
• glock - glock: migrate to buildGoModule #318572
• go-symbols - go-symbols: migrate to buildGoModule #318272
• govers - govers: migrate to buildGoModule #318229
• grafana-reporter - grafana-reporter: migrate to buildGoModule #318613
• guardian-agent - guardian-agent: remove #318616
• kontemplate - kontemplate: migrate to buildGoModule #318627
• librarian-puppet-go - librarian-puppet-go: remove #318787
• mailhog - mailhog: migrate to buildGoModule #318254
• nex - nex: migrate to buildGoModule #318094
• notary - notary: 0.6.1 -> 0.6.1-unstable-2024-04-16 #318718
• prometheus-dovecot-exporter - dovecot_exporter: migrate to buildGoModule #318846
• prometheus-minio-exporter - minio-exporter: remove #318841
• prometheus-surfboard-exporter - prometheus-surfboard-exporter: migrate to buildGoModule #318268
• protoc-gen-twirp - protoc-gen-twirp: migrate to buildGoModule #318255
• simplehttp2server - simplehttp2server: migrate to buildGoModule #318095
• snicat - snicat: migrate to buildGoModule #318084
• ssm-session-manager-plugin - ssm-session-manager-plugin: migrate to buildGoModule #318850
• syncthing-tray - syncthing-tray: migrate to buildGoModule #318563
• tmsu - tmsu: migrate to buildGoModule #318316
• upower-notify - go-upower-notify: unstable-2016-03-10 -> 0-unstable-2019-01-06; migrate to buildGoModule #318082
• vndr - vndr: migrate to buildGoModule #318798
• xmonad-log - xmonad-log: 0.1.0 -> 0.1.0-unstable-2024-06-14  #318266

Pase 2: Mark buildGoPackage as deprecated

• buildGoPackage: deprecate #328876

Phase 3: Remove buildGoPackage

This will be done after the 24.10 branch-off.

• Remove buildGoPackage

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/deprecation-of-buildgopackage/46670/1

[ehmry]

Are you volunteering to add the mod files downstream?

[tie]

Are you volunteering to add the mod files downstream?

Why do we need this? Go modules were designed to be compatible with existing ecosystem. Worst case, you can use local go.{mod,sum}, similar to Gemfile{,.lock} we already have in Ruby language framework.
Am I missing something here? Does this use case not work with buildGoModule (to be honest, I wouldn’t be surprised if it doesn’t given that it’s not the most idiomatic Nix/Nixpkgs piece of code I’ve seen)?

[katexochen]

Are you volunteering to add the mod files downstream?

Not sure I get your question. I'm happy if people want to help with the migration.

[ehmry]

Sorry, I'm fine with migrating if we keep the packages we have, I just don't want to see packages declared unmaintained and removed because of changes in packaging practices.

[katexochen]

Sorry, I'm fine with migrating if we keep the packages we have, I just don't want to see packages declared unmaintained and removed because of changes in packaging practices.

I'd argue that this isn't a change in nixpkgs packaging practices, but rather a change in the Go ecosystem that these projects didn't follow -- sometimes, because it's difficult for them to make the switch or they are not willing to, but most of the time because the upstream project is just unmaintained (no reactions to issues/PRs, no commit for several years).

I also think it is fine to remove packages, for example if their upstream project is archived, or they are unmaintained and a burden to drag along, or simply lack relevance today (compare package acceptance criteria).

[AndersonTorres]

dep2nix has three years without updates:
https://github.com/nixcloud/dep2nix

[ehmry]

Software doesn't magically break after a year because no one was adding features. I thought that Go had a stable spec and standard library.

[Gerg-L]

I'm going to attempt to migrate docker

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/1016/136

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-already-reviewed/2617/1732

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/1016/138