Has anyone worked with #golang, #nix (with or without nix-shell), and #JetBrains GoLand?
My first passes at researching this doesn't show me many promising results. Some vscode discussion suggest launching vscode from the CLI after entering the shell.nix-enabled project directory, but not sure how I feel about that.
@emattiza Thanks for that! The article is one I saw but it's good to see someone else link it so it must not be too terrible.
It looks like they opted to just open the IDE from the shell. They did list two other (untested) options, though. The latter looks promising but see there are issues open for GoLand specifically not working. :-/
@beausimensen so i ran this from a fresh gitpod workspace (just my way of getting a relatively clean slate to start from with nix and direnv), and can run goland with the right config from the following branch. having a package definition is a big help, and this shoots you right into a develop shell on the package where you can do the manual build steps afterwards (thanks to direnv and use flake). https://github.com/emattiza/otel-cli/compare/main...emattiza:otel-cli:add-nix-flake?expand=1
@beausimensen was just trying to show the diff, thats the branch. basically you can put a flake in a subfolder (or root, your choice really) and then put the package definition in there too. having a default package in the nix flake means nix develop calls will use the buildEnv of the default package in the new shell. direnv use flake hooks it up so you run nix develop on directory enter. going into goland after this should pick up the go from nix instead of system.
@emattiza OK. So I’m sure I’m following… this is using direnv but NOT using nix-shell and shell.nix at all (“use nix”). Instead, it’s hooking direnv into a flake (“use flake”). Also, the intention is to open goland from this shell and not open it via GUI. Is that right?
How did you know what to do for application.nix? Like, preCheck and passthru.updateScript? Boilerplate or learned/experience? :)
I suspect this will be quite useful. Thank you so much!
@beausimensen you've got it right! you just enter directory, direnv does it's thing and pops you into a shell with all the deps of the package definition. then you can enter goland . once direnv is done, and open goland. the stuff in application.nix is whats in nixos/nixpkgs for this exact project, because i maintain that derivation and wrote some of it along with Colin. the preCheck and passthru are learned from maintaining nixpkgs derivations.
@emattiza Also, I was going to ask, “how did you know what the vendorHash would be?” but that’s a road I’ve been down before and it is still baffling to me. :)
I think I needed to do this when building an overlay for mutagen.
@beausimensen there are ... oddities about how you would go about prefetching that info. i remember a couple years ago cmickens got it sorted, but that method above (faking hashes and setting it right while monitoring diffs of mods and sums for weird/malicious dep changes) is good enough and quick enough to not worry about getting fancy
@beausimensen also, nix repl is your friend for finding things out, and using :lf contrib/# will load all the attributes from the flake so you can look at them and see what is what
@emattiza Alright, I’m finally back on track. I was finally able to get goland installed as a system package. It took me a long time to figure out how to get my particular setup to work with impure/non-free packages. :-/ But! I’m there. Thank you so much. :)
Add comment