{"comment":{"url":"https://api.github.com/repos/NixOS/nixpkgs/comments/16625766","html_url":"https://github.com/NixOS/nixpkgs/commit/7760d6e02dbf85140a21d398228182db13270d62#commitcomment-16625766","id":16625766,"user":{"login":"edolstra","id":1148549,"avatar_url":"https://avatars.githubusercontent.com/u/1148549?v=3","gravatar_id":"","url":"https://api.github.com/users/edolstra","html_url":"https://github.com/edolstra","followers_url":"https://api.github.com/users/edolstra/followers","following_url":"https://api.github.com/users/edolstra/following{/other_user}","gists_url":"https://api.github.com/users/edolstra/gists{/gist_id}","starred_url":"https://api.github.com/users/edolstra/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/edolstra/subscriptions","organizations_url":"https://api.github.com/users/edolstra/orgs","repos_url":"https://api.github.com/users/edolstra/repos","events_url":"https://api.github.com/users/edolstra/events{/privacy}","received_events_url":"https://api.github.com/users/edolstra/received_events","type":"User","site_admin":false},"position":null,"line":null,"path":"","commit_id":"7760d6e02dbf85140a21d398228182db13270d62","created_at":"2016-03-10T18:58:35Z","updated_at":"2016-03-10T18:58:35Z","body":"Yeah, sorry for being a bit abrupt about reverting this, but I've learned it's better to revert quickly when dealing with commits that have a potentially high impact. (E.g. last year wkennington introduced some new derivation style that IMHO wasn't a good idea, and when I finally decided to revert that, it took me half a day to untangle the web of commits that depended on those changes. In this case there were already two commits depending on this commit. Since `go-packages.nix` contains hundreds of packages, )\r\n\r\nNote I'm not necessarily opposed to this commit, but it's kind of a \"strategic\" change that requires some careful thought, for these reasons:\r\n\r\n* It introduces the notion of writing packages in JSON format rather than as Nix expressions. I don't know if that's something we want to promote. In any case it's a new derivation style, and those should always be carefully considered since they make it harder for people to understand / modify a package.\r\n\r\n* It introduces yet another auto-update mechanism, and we already have a lot of those, most of them only used by the person who introduced them. (E.g. `gnupdate`, the `.upstream` files, language-specific mechanisms...) This too raises the burden for someone else to modify a package because they have to figure out how the particular auto-updater for that package works. We should really come up with a universal auto-update tool, or at least a standard for what they should do (e.g. update Nix expressions in place or overwrite an external version file?).\r\n\r\n* (Slightly tangential) It further entrenches `go-packages.nix`, which I already objected to when it was introduced. We don't have a giant `c-packages.nix` for everything written in C either. Having one big file is suboptimal e.g. due to the risk of conflicts between different PRs, inability to do `git log` to see the history of an individual package, etc.\r\n\r\nThe meta-problem is of course that we don't have a good process for dealing with such changes. Hopefully #13602 will help a bit with that.\r\n"}}