I ran into a Go package (github.com/gogits/gogs) that had two libraries named i18n in its dependency graph, but from different repositories, and it caused a conflict in the map because the i18n attribute was specified twice.
This problem is solved by having just a flat array. Another option would be to somehow include the full repo in the attribute name, but I don't think it's practical (and doesn't match what's used in the current nixpkgs.goPackages attributs names. Or maybe automatically add a number after the dependency name if one with the same name already exist?
But I think with the upcoming new nixpkgs.goPackages structure, there will be nested hash maps with Github username and repository name, so it would also fix this name conflict.
Note: this PR is more to open a discussion than to be merged right away, because I also find having a hash map including the package name pretty convenient, especially when converting the expressions to nixpkgs.goPackages definition.
I ran into a Go package (
github.com/gogits/gogs) that had two libraries namedi18nin its dependency graph, but from different repositories, and it caused a conflict in the map because thei18nattribute was specified twice.This problem is solved by having just a flat array. Another option would be to somehow include the full repo in the attribute name, but I don't think it's practical (and doesn't match what's used in the current
nixpkgs.goPackagesattributs names. Or maybe automatically add a number after the dependency name if one with the same name already exist?But I think with the upcoming new
nixpkgs.goPackagesstructure, there will be nested hash maps with Github username and repository name, so it would also fix this name conflict.Note: this PR is more to open a discussion than to be merged right away, because I also find having a hash map including the package name pretty convenient, especially when converting the expressions to
nixpkgs.goPackagesdefinition.