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.
> 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.
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.