Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Devenv.sh: Fast and reproducible developer environments using Nix

devenv.sh

Post reply on HN
Print view View original

161–170 of 171 posts

Re: Devenv.sh: Fast and reproducible developer environments using Nix

#161

Post by airocker »

pxc wrote: post #159
airocker wrote: post #144

Earlier quoted context omitted.

The easy way to understand nix is : "A package manager that can compile all packages from source", this functional mumbo-jumbo is just confusing. If apt could compile all its packages from source with an option to do so and a cache, it would be as reproducible.

Debian packages are also built from source, but their model for building and distributing packages has a different ontology, it considers different kinds of resources than Nix does. > If apt could compile all its packages from source with an option to do so and a cache, it would be as reproducible. This is simply wrong. There are many source-based package managers besides Nix: Portage, Sorcery, Pkgsrc, Ravenports, Ma…

I read a little more, you are right. There is definitely niceness but time will tell if all package maintainers will move to nix. IF they do, it will be great that dev mode and deploy mode can be all nix. Until then, not sure why I would use nix for developer workspaces.

Re: Devenv.sh: Fast and reproducible developer environments using Nix

#162

Post by mikepurvis »

pxc wrote: post #151
mikepurvis wrote: post #134

Earlier quoted context omitted.

Based on the amount of patching and such that is necessary in many packages, plus the constraint of not linking two different versions of libXYZ into your final binary, I'd expect it would be pretty hard to have a truly unified environment of multiple nixpkgs pins, at least without a facility for maintaining another big patching layer.

You'd want to be using old Nixpkgs definitions as a starting point for importing a package definition that will work with a package's build system at the given version, and trying to rebuild it against the libs that are already in your environment. You could do the same basic versioned dependency solving all the way down your dependency tree using the same tool, whenever one of the recipes expected a version not in y…

I might just lack imagination, but I think the wheels are already well in motion for at least one significant piece, which is many more upstream maintainers having some awareness of Nix and Guix (and now Tea too, I guess) and understanding the value of things like reproducibility, relocateability, not accessing the network during build, not making assumptions about where stuff will be located or that the different build outputs (lib/bin, dev, doc, whatever) may end up in fully separate trees. This goes doubly so for tools maintainers like the people at Kitware, who wield an enormous amount of power in steering devs toward patterns that allow software to be packaged for Nix with minimal patching.

All this lowers the fragility of the package definition and I think helps increase the likelihood of that software being forward- and backward-compatible with different versions of its underlying dependency pool.

Re: Devenv.sh: Fast and reproducible developer environments using Nix

#163

Post by throwawayacc4 »

baby wrote: post #150
throwawayacc4 wrote: post #84

Earlier quoted context omitted.

Containers run nearly identical to native performance and best VMs in practically every category. In what way are they slow?

On my mac it’s really slow to use docker. Maybe I should increase the ram it uses

I don't use Apple products so I can't help you there. I assume it's doing some networking madness to expose a Linux VM through a bridge or something similar.

Re: Devenv.sh: Fast and reproducible developer environments using Nix

#164

Post by iopq »

airocker wrote: post #143
iopq wrote: post #97

Earlier quoted context omitted.

You're right, we should work on everyone using NixOS, that way dev and deploy is the same :)

well in that case, the easy way to understand nix is : "A new linux variant and package manager that can compile all packages from source". Why confuse users it has anything to do with dev environments. If your initial product is for development spaces only, it will only complicate things and nobody would use.

But that's not the best part, the best part is having all of the packages and having them work without dependency hell

Re: Devenv.sh: Fast and reproducible developer environments using Nix

#165

Post by airocker »

iopq wrote: post #164
airocker wrote: post #143

Earlier quoted context omitted.

well in that case, the easy way to understand nix is : "A new linux variant and package manager that can compile all packages from source". Why confuse users it has anything to do with dev environments. If your initial product is for development spaces only, it will only complicate things and nobody would use.

But that's not the best part, the best part is having all of the packages and having them work without dependency hell

The concept is definitely nice.

Re: Devenv.sh: Fast and reproducible developer environments using Nix

#166

Post by andyrichardson »

solatic wrote: post #85

There's a long tail of issues that continue to plague Nix. Sometimes, not even the fault of the Nix project itself. Case in point for my current employer's Python shop - everyone runs PyCharm. Well, JetBrains doesn't really support Nix-based environments. See e.g. https://youtrack.jetbrains.com/issue/PY-42461 . So basically something like this would be DOA. Is this something that someone like @domenkozar can fix? @gr…

Having used Fedora Silverblue in the past, I went all in on nixOS as it seemed perfect for me.

Setup was easier than Arch and I had more trust in the stability of the system because there's no state/config that I wasn't aware of (albeit after a learning curve).

The biggest issue though is how rigid it is. The "nix way" spreads like a plague into everything and I often felt like I couldn't do basic tasks such as install some node modules without having to relearn how to do it in nix.

I told myself that FHS was a good enough fallback, but that just wasn't the case. Despite using FHS for node development, I still encountered nix-specific issues that needed a nix-specific fix (i.e. using prisma binaries).

Re: Devenv.sh: Fast and reproducible developer environments using Nix

#167

Post by School-Cotton »

baby wrote: post #150
throwawayacc4 wrote: post #84

Earlier quoted context omitted.

Containers run nearly identical to native performance and best VMs in practically every category. In what way are they slow?

On my mac it’s really slow to use docker. Maybe I should increase the ram it uses

Docker containers run in a VM on Mac.

Re: Devenv.sh: Fast and reproducible developer environments using Nix

#168

Post by solatic »

andyrichardson wrote: post #166
solatic wrote: post #85

There's a long tail of issues that continue to plague Nix. Sometimes, not even the fault of the Nix project itself. Case in point for my current employer's Python shop - everyone runs PyCharm. Well, JetBrains doesn't really support Nix-based environments. See e.g. https://youtrack.jetbrains.com/issue/PY-42461 . So basically something like this would be DOA. Is this something that someone like @domenkozar can fix? @gr…

Having used Fedora Silverblue in the past, I went all in on nixOS as it seemed perfect for me. Setup was easier than Arch and I had more trust in the stability of the system because there's no state/config that I wasn't aware of (albeit after a learning curve). The biggest issue though is how rigid it is. The "nix way" spreads like a plague into everything and I often felt like I couldn't do basic tasks such as insta…

Yeah I ran into this with Flutter, where upstream's install method boiled down to "Clone the Git repo and allow Flutter to write into the path where the repo is cloned to in an ad-hoc manner." Needless to say, huge conflict with the Nix Way. When the Flutter 2 -> 3 migration happened, the upgrade for the Nix package was taking so long (months) that I eventually said, you know what, screw it, I can't let productivity get bogged down for a reason like that.

I still believe that the Nix way is the right approach, it's just going to take more time to mature out the Nix ecosystem's integrations with various language and package ecosystems to make it more dependable for developers.

Re: Devenv.sh: Fast and reproducible developer environments using Nix

#169

Post by colinsane »

throwaway892238 wrote: post #40
colinsane wrote: post #27

this, devbox, and others seem to be alternatives to `nix-env shell` or the flake-based `nix develop`. spurred i think by a desire for better UX. these are excellent for any project off-the-ground enough that you’ve run `git init` or created a repo. the adjacent area i’m struggling with is the “i want to write a tiny program to verify some conjecture, and i’ll probably throw it away an hour from now”. think codegolf c…

> I’d love a tool where i can just `cd /tmp/my-hourlong-project` and then `devenv python` to get a python shell that’ll have everything i often use (and probably more) There's a dozen projects that do this. But it would honestly take you as much time to write a shell script to do it as use some other project to do it. Like, seriously: #!/usr/bin/env sh set -eu [ "${DEBUG:-0}" = "1" ] && set -x MY_TEMPLATE="${MY_TEMPL…

oh, for sure. but then take a look at qbasic_forever's sibling comment: by embracing a common shared tool to do this, i also get some nice tools for enumerating templates, with descriptions; i can share my own templates with other nix users without asking them to copy my weird shell scripts, and the reverse; and so on.

don't mistake me for a lazy user in the sense of "doesn't want to write my own code". i'm actually the type of lazy user who prefers to find a project that gets me 80% of the way there, patch it where it falls short, and then upstream my changes so that i don't have to maintain an ever-growing pile of custom patches and one-off shell scripts on my lonesome ;-)

Re: Devenv.sh: Fast and reproducible developer environments using Nix

#170

Post by v3ss0n »

FactoryReboot wrote: post #110
v3ss0n wrote: post #68

Earlier quoted context omitted.

Fine, let's just develop on production. Cases solved

Good idea. Let’s go beyond merely testing in prod

Cut cloud cost by half, no more 'it works on my machine ' problem, it just works or it won't.
Post reply on HN