Change:
<ins> { stdenv, buildGoPackage, fetchFromGitHub }: buildGoPackage rec { name    = "exercism-${version}"; version = "2.3.0"; goPackagePath = "github.com/exercism/cli"; src = fetchFromGitHub { owner  = "exercism"; repo   = "cli"; rev    = "v${version}"; sha256 = "1zhvvmsh5kw739kylk0bqj1wa6vjyahz43dlxdpv42h8gfiiksf5"; }; meta = with stdenv.lib; { description = "A Go based command line tool for exercism.io"; homepage    = http://exercism.io/cli; license     = licenses.mit; maintainers = [ maintainers.rbasso ]; platforms   = platforms.linux; }; } </ins>

Discussion:
Hello, I wanted to install exercism and thought that I should first look if there is not a Nix package for it. I did not find it with nor with but I found traces that there existed such a package (first as a binary, then as a goPackage) by searching this repository. Was support for this package dropped? If so, was it dropped voluntarily? I did not find any trace of a discussion on dropping it but maybe it happened somewhere anyway. If the package is still there, somehow, what should I have done to find it? Thanks! PS: tagging since he was listed as maintainer of the original binary package.
I think, it go removed by this pull request: You can restore this package, if you want.
Indeed! For some reason it did not appear in and thus was forgotten from this pull request. Not being a Go developer myself, I'm not sure how I could restore it properly.
cc
It looks like it wasn't exposed to before and that's why it was removed. I can get it back and expose it as top level package if you want.
FWIW, I used to refer to lots of (just like I do with and so on; would you delete most of those too?) so exposing at the top level doesn't really feel like the right criterion.
The distinction between this particular package and most or is that this is providing an executable and not a library. It is a final-user package, not a development package. It was probably a mistake from the beginning not to expose it in . Now, it is true that lots of packages providing executable utilities for developers (and not libraries) are hidden inside such attribute sets as well. Drawing an example from what I know, is in such case. as well, but at least if I type the response tells me what its location is. Whereas, if I type the response is unhelpful. But at least I can find it with Whereas in the case of the Emacs mode Proof-General, I don't even find it there or with . I do not understand these distinctions. But I know that I have digressed.

Coming back to the original problem, if you restore the package, note that the latest version is now v2.3:
I'm not a Go programmer and I'm still trying to understand Nix and Nixpkgs, but I would like to pack because it is too boring to compile and install it manually. I would love some directions here... seems to work, but I don't know if this is the proper way to do it. Is it right? Suggestions? way it is, the package name comes out as instead of . Is this name structure also used for executables or just for libraries? install it, I have to type . Is it possible to make it work with ?
's ok, add some meta to it like (+ 3) There's no difference for libs/exec in now and I think that it could be a good move to change it to like that won't prefix app name.