undefined | Better HN

0 pointsxfer7y ago0 comments

> This is OK, but it feels wrong to me. It feels weird that launching Rider outside of nix-shell won't ever work, yet it's installed globally.

What do you mean it won't work? I think rider will launch without dotnet, If not then rider dependencies should be fixed to include dotnet. Otherwise, it's the same case for any other distro.

> but I don't think it belongs in version control.

Why not? In fact you should put them in vc since anyone with nix can easily build the program exactly same as on your machine.

> Should it be personally suited, with my IDE and developer tools?

You can create different nix files: e.g. in ide/default.nix you can inherit your default shell.nix and put extra dependency. You may want to skip checking this in vc though.

For a good organization of nix files look at the reflex-frp haskell project.

0 comments

2 comments · 1 top-level

jchw7y ago· 1 in thread

Rider launches without dotnet, but is not very useful. It becomes effectively a text editor.

Of course, if you wanted to use rider without dotnet, you could. But it doesn't fit my workflow.

And yes, like I said, this is still better than the situation on other distros, but it feels like it's close to being even better than that.

>Why not? In fact you should put them in vc since anyone with nix can easily build the program exactly same as on your machine.

For starters, because I work on a lot of projects that aren't mine. But also, because it's not really standardized.

Like there's a fairly standard practice for putting a package.json in a repository but not really so for default.nix. And it's also not exactly orthogonal to Nixpkgs; if you wanted your project to be in Nixpkgs, your expression would be (slightly) different. That is probably solved by importing the Nixpkg into default.nix, but I haven't tried yet.

Finally, this doesn't capture everything. If I want an environment where I have VSCode with the Go extension installed, I would prefer that to be isolated from other VSCode instances.

That's why I think I want more than just a Nix expression. The tools to do what I want are all here, but the tool to automate the workflow is not.

xferOP7y ago

> If I want an environment where I have VSCode with the Go extension installed, I would prefer that to be isolated from other VSCode instances.

You can absolutely do this by overriding the derivations. The tool to automate your workflow is there(just create a bunch of nix files and a makefile to call nix-shell/nix-build), but not as convenient as you might like.

j / k navigate · click thread line to collapse