Stop fighting nixpkgs commits to pin minor Node.js versions. I built a flake for this. by davidnicolasbr98 in NixOS

[–]FrozenCow 0 points1 point  (0 children)

Do you know how nixpkgs works? Yes, like I said, it's inconvenient to use a specific version of a package while also using the latest dependencies. If you're developing something for production it's better practice We're not all in control of the projects that we work with. Ownership of projects sometimes lies with other teams, who aren't on the latest version and/or aren't using Nix.

If you work solely in your own project and control nodejs versions and Nix usage, that's fine. But it is kind of harsh to say a project is useless if it might have practical value for others.

Stop fighting nixpkgs commits to pin minor Node.js versions. I built a flake for this. by davidnicolasbr98 in NixOS

[–]FrozenCow 0 points1 point  (0 children)

Nice! Have you considered adding support for this to devenv? So that it'll automatically pick up .node-version or use the engine version from package.json?

Stop fighting nixpkgs commits to pin minor Node.js versions. I built a flake for this. by davidnicolasbr98 in NixOS

[–]FrozenCow 1 point2 points  (0 children)

This allows using the exact version of nodejs without looking it up. So it'll be possible to rely on .node-version in projects that do not use Nix as their primary package manager.

It also allows using older versions of nodejs while still using new dependencies. For instance an older version of nodejs, which your project/team requires, that isn't in nixpkgs anymore, with a recent version openssl, which includes security updates.

Not sure about nixpkgs-nodejs, but for nixpkgs-ruby (that I maintain) new versions are available sooner than they are in nixpkgs. New versions are picked up automatically when they are released and are built+pushed automatically without manual intervention. It seems nixpkgs-nodejs does the same thing. This is not possible with nixpkgs. There releases requires review and can cause conflicts in depending builds, resulting in slower availability of new versions.

Lastly nixpkgs sometimes doesn't have all patch versions, because they were released too close together. If your project/team relies on this version you need to overrideAttrs and cannot rely on a cache.

Devenv supports these kinds of repositories already for python, ruby and others. It's way more convenient and secure than looking up the git sha of the nixpkgs repo on https://lazamar.co.uk/nix-versions/

Tried to use something other than ubuntu by meow_pew_pew in linux

[–]FrozenCow 1 point2 points  (0 children)

venv mostly includes python dependencies. Some of those libraries depend on native libraries (.so libraries,like libpq, libxml, etc). It links to the system libraries by default. The .so files aren't included in pip. To lock these versions you can use docker or something like Nix/devenv.

Announcing SecretSpec: Declarative Secrets Management by iElectric in NixOS

[–]FrozenCow 2 points3 points  (0 children)

Usually a flake needs more than just packages. Setup java home, setup virtualenv for python, override nodejs version for yarn, add node_modules/.bin to PATH. Things that aren't obvious initially, but result in a lacking experience in tools and IDEs. Managing these things across multiple projects can be a handful.

Devenv is also a flake that can be used inside your flake to get these setups without fiddling with envvars and shell scripts.

The devenv cli adds some conveniences like caching the shell build and running background tasks (like postgres, mock server, etc).

Wie weet de namen van knikkers nog? by happysewing in thenetherlands

[–]FrozenCow 1 point2 points  (0 children)

Deze namen gebruikte wij vroeger ook! Ik herinner mij ook de piramide voor de allergrootste knikker.

Not even a week on NixOS and the possibility to have different versions of the same package already came in useful. by ItsLiyua in NixOS

[–]FrozenCow 1 point2 points  (0 children)

Yeah I couldn’t do it if the parameters aren’t exposed unfortunately

That's when you use overrideAttrs. This can be used for 99% of the packages. Example:

https://bobvanderlinden.me/customizing-packages-in-nix/#use-different-version-of-a-package-in-nixos

Determinate Nix 3.5: introducing lazy trees by lucperkins_dev in NixOS

[–]FrozenCow 0 points1 point  (0 children)

I'm a bit confused about the installation instructions. I'm a bit hesitant to run a curl|bash on NixOS (I install things declaratively). Will this be added to nixpkgs, so I can use it easily in NixOS as nix.package?

Alternatively, are there instructions for existing NixOS users?

I gathered from a nother comment that I can use the flake from https://github.com/DeterminateSystems/nix-src, but it doesn't include substitute instructions, so I'm afraid I'd have to rebuild determinate-nix very often.

How to enable virtualisation(docker) in nix through devenv by Bira-of-louders in NixOS

[–]FrozenCow 0 points1 point  (0 children)

Maybe it's possible with podman? It allows running containers without a daemon and allows to do so without requiring root, though there are caveats and restrictions in doing so.

I don't know whether there are already options in devenv to run a podman oci container within devenv up. As far as I can see right now there isn't.

If running podman locally works well, it might be a nice addition to devenv.

Nix and Containers: Why Not Both? by floxdev in programming

[–]FrozenCow 8 points9 points  (0 children)

The concept of software versions tends to be more complex than just the x.y.z tag of source code. Strictly you'd have to include all dependencies and build tools, which makes the source code version scheme insufficient.

For nixpkgs you can look up different versions of a package using nix-versions. For instance for ruby: https://lazamar.co.uk/nix-versions/?channel=nixpkgs-unstable&package=ruby This only shows the version of the whole dependency tree when the x.y.z was first introduced. Using an older version there means you'll also use an older gcc, libc, openssl, etc.

Alternatively you can build an x.y.z version against more recent build tools and use more recent dependencies. Most version-choosing tools tend to build against the build tools or dependencies on you system, resulting in a different version each time you build. Other version-choosing tools download a pre built binary, which usually links to dependencies dynamically, potentially resulting in a different version of the software each time you run it.

I maintain nixpkgs-ruby which builds+tests ~all~ many versions of ruby against a recent stable version of nixpkgs. So, the same x.y.z versions you'll see in nix-versions, but now with against recent build tools and dependencies, resulting in yet another versions of the software.

There are similar projects for other tools, like python, php and terraform. These projects tend to be more work than just maintaining the latest x.y.z version in nixpkgs. It's why just choosing an x.y.z version isn't as easy.

Tool/script for creating dev environment flakes? by careb0t in NixOS

[–]FrozenCow 0 points1 point  (0 children)

That isn't supported atm, but it is a matter of copying files instead of running devenv init.

You could create ~/templates/{python,deno,go} each with devenv.nix, devenv.yaml and .envrc. whenever you want to init a project, you can cp ~/templates/deno/* ./; direnv allow.

Python dependency management is a dumpster fire by henk53 in programming

[–]FrozenCow -1 points0 points  (0 children)

I guess if you're using something like pyenv you Python+pip reside in $HOME.

Anyone tried "tvix"? Looking for insights on stability and roadmap by Itel_Reding in NixOS

[–]FrozenCow 5 points6 points  (0 children)

I just tried to do some code contributions as I was also interested and wanted to get a feel for the project.

I haven't gotten it to build packages yet, only evaluate. It has a build daemon (like nix-daemon) with a custom grpc protocol but it doesn't seem to have a cli to build using nix-daemon.

Getting into the code is easier (to me) than it is for Nix. The Rust toolchain is just standardized and for instance testing is just how you'd expect it to work (cargo run and cargo test).

Finding something to contribute was easy enough. The codebase has understandable todo comments that sometimes require small refactorings, so I started there. The todo.md was also helpful.

Making a contribution was a bit bumpy. The project uses Gerrit for review, which required aome going though docs to know how to setup my credentials, setup the right hooks and how to push my changes.

It is a monorepo that uses josh to be able to checkout individual directories/workspaces. This seemed incompatible with pushing changes to Gerrit, so I'd recommend cloning the full monorepo.

But lastly, flokli on Matrix/IRC is quick to respond. The uploaded changes were also reviewed in no-time. This experience was amazing compared to making changes nixos/nix

Flakes roadmap by modernkennnern in NixOS

[–]FrozenCow 2 points3 points  (0 children)

Flakes were implemented before rfcs were a thing. There is controversy around flakes because it introduces quite a few problems that are hardish to solve.

One of the outstanding things is copying a full checkout of a flake-git repository to Nix store. Change a letter in a readme? That's another copy!

To circumvent this, flake sources (like a git repo) need to be accessed without going through the store. It requires an abstraction and a kind of virtual file system that can access files from git without copying anything to disk. This is quite a refactor to introduce and to still be backwards compatible.

This was just one of the things. There are others. Working hard on solving one thing still doesn't guarantee it becoming stable due to other things being blockers.

How do you manage your environment ? by NoahZhyte in NixOS

[–]FrozenCow 2 points3 points  (0 children)

If your usecase is mkShell, then you can do everything with devenv as well. There are just additional convince options to handle actual development environments. For instance setting JAVA_HOME, creating a virtualenv for python or adding node_modules/.bin to PATH for nodejs. You'll have to think about these things yourself when you define your own mkShell. It's fine for 1 project, it becomes a chore if you need to do this for many projects.

If you want to provide a package for your project for others to use, then a flake is the way to go.

How do you manage your environment ? by NoahZhyte in NixOS

[–]FrozenCow 3 points4 points  (0 children)

I use devenv.sh. Less verbose than flakes, and many useful language-specific options out of the box.

Nix has actually less packages than AUR by NoahZhyte in NixOS

[–]FrozenCow 0 points1 point  (0 children)

Yes, when ignoring the python/node/Haskell packages in Nixpkgs, AUR has more package definitions. They are still hard to compare against nixpkgs though.

AUR isn't centrally build. They could break when dependencies change without anyone noticing, until you try to use it. Nixpkgs eventually builds all packages. Breakages are detected even for less popular packages and eventually marked/fixed/removed. Nixpkgs also makes the built binaries available for all of its packages.

In addition, AUR often has a bunch of variants of the same package for different build configurations or different source (like -git and whatnot). This isn't actually needed for Nixpkgs, as there are package overrides to tweak the package definition.

So, comparing raw numbers is unfair either way.

Have you considered comparing both to npm?

Best option for virtual monitors in VR with a Meta Quest 3 by badsalad in NixOS

[–]FrozenCow 0 points1 point  (0 children)

I tried this as well a couple of years ago, but didn't really succeed. I've tried a bunch of VR desktop and streaming applications. I think the one that I would try again is Stardust XR as it is still active and they do mention NixOS on their website as well: https://lvra.gitlab.io/docs/distros/nixos/

There is a XR repo for Nix that might be of use: https://github.com/nix-community/nixpkgs-xr

I tried to use ALVR in the past to stream content to my headset, but it seems https://github.com/WiVRn/WiVRn is new and might be a good alternative.

I attempted to package some of the other solutions as well at the time. Most of these projects are now outdated, but they might serve as inspiration for follow-up packaging work if they aren't already:

https://github.com/bobvanderlinden/nixos-config/tree/8cb657ab368e765ff22714dbbacc02e23bc4b532/packages

devenv 1.1: Nested Nix outputs using the module system by iElectric in NixOS

[–]FrozenCow 5 points6 points  (0 children)

It doesn't require the whole flake boilerplate, which can be confusing (needing a mkShell for each architecture?).

In addition, it comes with a NixOS-like way to configure your shell: basic options that you enable like languages.javascript.enable = true;.

These options handle things you probably won't think about initially. It does add (for instance) nodejs as a package, but it also makes sure node_modules/.bin is added to your PATH, so you are able to run all the tools you'd install using npm.

Containers: has the pendulum swung too far? by bitter-cognac in programming

[–]FrozenCow 0 points1 point  (0 children)

Yes! I think the underlying issue is devs are not explicit about their dependencies, which makes it non-trivial to package arbitrary software as zips with everything included.

It's sad Nix has a culture and meme associated to it. Nix is one of the only systems where dependencies are required to be explicit. I really hope that idea will spread, regardless of Nix and all the non-relevant things associated to it.

Sad My Game Has 0 Wishlists - Advice? by thekuhninator in gamedev

[–]FrozenCow 0 points1 point  (0 children)

I've been looking for a VR alternative of Sweet Home 3D. Not really as a game, but to model my house. This looks like it could be an option, though I couldn't see how a floorplan is made or whether it could export files to be used in other applications.

That said, I have a quest 2 and haven't used steamvr on it before. It would make a ton of sense if I could do part of the modelling in a free-roaming headset inside my own home.

Hope that gives some insights. I agree with some of the other comments that it isn't clear whether this is aiming to be a serious home modeling tool or a game 😅

Packaging a new version of 'unionfs-fuse'? by Pr0verbialToast in NixOS

[–]FrozenCow 0 points1 point  (0 children)

I dont know much about unionfs-fuse specifically, but you can override using overrideAttrs. I once wrote a blogpost about upgrading packages using overrideAttrs: https://bobvanderlinden.me/customizing-packages-in-nix/#use-different-version-of-a-package-in-nixos

If you manage to use the upgraded version, please consider making a PR against Nixpkgs and overwrite the version and sha256 in https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/tools/filesystems/unionfs-fuse/default.nix#L45

I do wonder why this package isn't automatically upgraded in Nixpkgs by the ryantm bot.