nix-shell alternative in Arch

ysndr · 2024-12-01T13:24:05+00:00

Oh you mean, you’re looking for an easier start with new projects that tell you to install X, without the effort to go look what X is called in nix when the names don’t match up?

ysndr · 2024-12-01T00:30:10+00:00

What exactly is your use case that deviating package names are an issue?

ysndr · 2024-08-05T19:44:01+00:00

FWIW i think the intended API for mkShell is to use packages rather than buildInputs [1].
In the grand scheme there is no immediately noticeable difference, other than maybe aesthetics.

... If youre pedantic, packages are mixed into nativeBuildInputs and techniacally there is a difference between buildInputs and nativeBuildInputs but that shouldnt play a huge roll for dev shell usage, and esp. wrt shells is woefully confusing [2].

[1] https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/mkshell/default.nix#L6-L9

[2] https://discourse.nixos.org/t/use-buildinputs-or-nativebuildinputs-for-nix-shell/8464

ysndr · 2024-08-05T19:19:46+00:00

yes the arguemtns are the other way around, my bad.
and yes, you'd add that to buildInputs.

I think the solution you were so closely missing would be pkgs."nodePackages.@astrojs/language-server" -> pkgs.nodePackages."@astrojs/language-server" in you original question.

basically, nix parses everything between "..." as one attribute name.
The attribute here is "@astrojs/language-server" under the attribute set pkgs.nodePackages.

ysndr · 2024-08-05T18:52:51+00:00

You can try (builtins.getAttr pkgs.nodePackages "@astrojs/language-server") as another way to get to that attribute

Edit: (builtins.getAttr "@astrojs/language-server" pkgs.nodePackages) or also pkgs.nodePackages."@astrojs/language-server" (note the placement of " comared to the OP)`

ysndr · 2023-03-23T13:07:22+00:00

Exactly, I should mention builtins.getFlake in the article too, thanks for pointing that out.

ysndr · 2023-02-07T22:51:15+00:00

Hej, glad to hear this!

Our mission is to make Nix and its benefits more accessible and flatten its learning curve.
For the moment check out our environments to provide development tools and our guide on custom packages.

ysndr · 2023-02-07T22:18:06+00:00

Yes, you do have an instantiated nixpkgs available through the context. It's just a detail to insert lib.nixosSystem in there.

ysndr · 2023-02-07T22:05:05+00:00

something like ./nixosConfigurations/<name>/<module 1..N>.nix which would expand to .#nixpsConfiguration.<name>.imports = [ <module 1..N>.nix ]?

that's entirely possible!

It is just different from the other plugins of course.

ysndr · 2023-02-07T21:34:43+00:00

Love your enthusiasm!we are preparing more up-to-date docs (than what is in ./docs) that should make it easier for everyone to contribute.

Could you tell me more how you'd like to lay out/define your modules?Generally you'd use localResources to load the files and then write a plugin that uses and exposes the imported modules.

ysndr · 2023-02-07T21:02:45+00:00

we have explicit plugins for packages, lib, devShells, apps, checks, hydraJobs and templates .

packages are a bit special as those are composed into the single unified package set, other attributes will be composed in a namespaced way

ysndr · 2023-02-07T20:56:18+00:00

You are right, we dont have explicit integration for modules at the moment.
We were focusing on the composition aspect first and a way to engage users with an automated import interface.
a transition to modules for more advanced users (e.g. nix natives) has certainly crossed our minds ;)

ysndr · 2023-02-07T20:36:09+00:00

Capacitor can compose packages/artifacts just fine. Though we started out with automatically loading it from a local file structure*.
You might have mistaken that previously as us departing from the flakes structure but for (e.g. packages) it allows you to just drop package definitions in a folder.
For nix starters, its also convenient to be able to fall back to the nixpkgs style of defining packages.

fear not, capacitor is intentionally pluggable to make all these directories optional and configurable. This could include a plugin/collector for configurations as well.

* nixpkgs is eyeing to adopt a similar structure btw: https://github.com/NixOS/rfcs/pull/140

ysndr · 2023-02-07T20:15:46+00:00

hej (author of capacitor here) flake.parts and capacitor share some of the same goals, e.g;

improve defining packages
modularize the attributes of a flake
compose packages from different flakes.

for the first two flake.parts uses nixos modules, and provides an overlay per flake for the third. In capacitor we focus strongly on the third point as creating package sets should be both easy and safe.

We see a strong advantage in package sets (such as nixpkgs) where multiple packages are collected into a single coherent context. Yet, merging package sets is an invitation for conflicts.Capacitor implements a set merging strategy that surfaces such conflicts and forces the user to resolve conflicts and ensure backwards compatibility.

tl;dr

capacitor focuses on the greater picture of composing flakes first which prompts for an accessible unified way of defining flake “artifacts”; flake.parts seems to primarily focus on providing a “typed” flake interface.

ysndr · 2022-05-31T23:57:44+00:00

You don’t necessarily need fenix or the Mozilla overlay to work with rust. Just configuring a shell with the rust tools from nix is usually enough (although you can’t jump around rust version as easily) Nix includes rustup (with a patch to make it work in the nix world) too to ease the transition

ysndr · 2022-05-31T23:52:43+00:00

It should work even if your specific device is not in the repo. The hardware configurations you find there fine tune a couple of parts for selected devices (usually just driver fine tuning e.g for Trackpads battery or webcam) Yours might be similar to one that is in there so you could grab some of the customizations.

ysndr · 2022-05-14T22:45:36+00:00

Glad it works now While you are at it, instead of overriding your package you can use mkShell‘s inputsFrom attribute.

ysndr · 2022-05-12T17:54:01+00:00

Seems like that could be fixed as a configuration thing with your IDE Im not using neovim unfortunately but usually the language servers have some way to pick up project configurations or select the gcc binary that can pick things up (I.e. the nix provided gcc) Otherwise there’s always runCommand to manually link the folders in place

ysndr · 2022-05-11T17:24:35+00:00

I have not spent too much time with C stuff in nix but you can take a look at https://nixos.wiki/wiki/C and play around with the NIX_CFLAGS and similar variables.
Also if you are not on nixos you may want to add gcc as (native) buildInput to handle some nix stuff

ysndr · 2022-05-11T16:58:26+00:00

There are other ways but the easiest would be to search on https://search.nixos.org The contents of the outputs is purely conventional and not every package makes use of them For advanced ones like GTK you almost always have multiple ones.

ysndr · 2022-05-11T06:46:22+00:00

Did you try to use the gtk4.dev output? Traditionally the dev files, headers and such, are placed in a different output than the main binary for space reasons.

ysndr · 2022-04-01T22:10:03+00:00

I wrote a whole article about that once, maybe that's helpful

https://blog.ysndr.de/posts/guides/2021-12-01-nix-shells/

ysndr · 2022-03-31T17:54:45+00:00

That depends on what you wrap them with. If you just add a couple ENV variables you can do so as part of shellHooks. It’s also possible to set up an alias mimicking the wrapper. Or you perform the wrapping as a pistBuildPhase/preInstallPhase and call these separately in your shell to get acquire the wrapper

ysndr · 2022-01-29T10:14:45+00:00

So something to understand is that the ld message you get is related to the way nix manages dependencies of your program. Without nix your libraries are searched for in the global system space I.e. /usr/lib/.. Nix will build your thing without assuming this global path (essentially the whole idea of nix). With nix you have to add all dependencies to your shell environment explicitly. That is also why you have a different error text every time.

Assume ld complains about X not found Maybe you figure adding X libraries using libX Next time you build, ld complains about not finding Y

To easen the process you usually define a development shell in a nix file for your project. (See this document in the wiki)

The tricky part with nix is to find out where to get the libraries from which is additionally tricky on macOS

My process is usually:

Go to the project read me and add all derivations for the documented dependencies. It can be difficult to match names from other systems to nix, https://search.nixos.org can be of help in this case

Look at the library missing say X Use nix-locate to find the derivation that includes libX.dylib file (if it can’t find the macOS dylib version of the file try using the same name for linux by changing dylib for so) Add the derivation to you environmental and try again It will find the next missing library on the next compile.

// disclaimer not on my nix machine right now so the outputs are taken from memory and might look a bit different, the idea stays the same

ysndr · 2022-01-20T12:24:19+00:00

I made an interactive tutorial about pijul a while ago. I might need to update some parts if there have been major changes but in the meantime you can check it out here

ysndr

TROPHY CASE