81–90 of 171 posts
Another project I've been following in this space (no affiliation) is Tangram ( https://www.tangram.dev/ ), which I think of as "Nix, but TypeScript" -- or, from their Discord: > Tangram takes a lot of inspiration from nix, and could be described as a mix between nix and bazel where you write JS/TS
Looks like there is no source available or even installation option?
Earlier quoted context omitted.
Would nix guarantee that all upstreams are available forever? Is nix planning to replace all upstreams? (PyPI, Conda, npm etc?) OR does it plan to keep a cache forever?
Nix doesn't keep a cache of the upstreams, though there are some projects planning to try to do that I think. The build recipes pull from the original source and use a hash to ensure that the source artifacts don't change. Nix caching is usually done at the build output layer, e.g. the resulting binaries.
Can someone explain to me the advantage of using Nix over containers? What do they offer that are not provided with using docker or other container platform.
Containers are way too slow, and take too much space (they don’t share dependencies). Also doesn’t necessarily play well with tools AND is hard to setup for dev environments (what do you mount?)
In what way are they slow?
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? @grhmc ? I don't know.
Another project I've been following in this space (no affiliation) is Tangram ( https://www.tangram.dev/ ), which I think of as "Nix, but TypeScript" -- or, from their Discord: > Tangram takes a lot of inspiration from nix, and could be described as a mix between nix and bazel where you write JS/TS
Looks like there is no source available or even installation option?
but I don't know what project among these GP was specifically referring to, perhaps it's not public at the moment
Unfortunately, Nix suffers the fate of Haskell: so powerful that the masses can't and don't use it. By contrast, Homebrew spreads like cancer. "Worse is better".
Earlier quoted context omitted.
Strictly compared to containers, the big advantages are reproducibility and lower overhead. Overhead: Windows and macOS can't run Linux-based containers natively. Instead, there's always a full Linux virtual machine running in the background acting as an intermediary and host for your containers. Nix can conjure arbitrary native development environments on a per-command or per-terminal basis, giving you all the perfo…
Would nix guarantee that all upstreams are available forever? Is nix planning to replace all upstreams? (PyPI, Conda, npm etc?) OR does it plan to keep a cache forever?
Guix, a similar project to Nix, has been tackling this head on by automatically falling back to the Software Heritage archive when the original upstream is unavailable: https://guix.gnu.org/en/blog/2019/connecting-reproducible-de...
Earlier quoted context omitted.
Nix doesn't keep a cache of the upstreams, though there are some projects planning to try to do that I think. The build recipes pull from the original source and use a hash to ensure that the source artifacts don't change. Nix caching is usually done at the build output layer, e.g. the resulting binaries.
So it does plan to replace all up streams eventually including apt, npm, pypi, gem etc by providing the ability to build and configure all software? I am not understanding this, currently the original maintainers release on their own stores. the build and configure steps may change over time. Unless the original maintainers start building for nix, would not this be too hard to maintain?
This is indeed very hard, but Nix's deep locking makes this a tractable problem: if a version of a package builds once, it will keep building for as long as the source code is available.
So in some ways, this Nix has an easier job compared to traditional distribution mechanisms. On the other hand, Nix can be sufficiently weird and unwieldy as to limit the number of potential contributors.
Earlier quoted context omitted.
Strictly compared to containers, the big advantages are reproducibility and lower overhead. Overhead: Windows and macOS can't run Linux-based containers natively. Instead, there's always a full Linux virtual machine running in the background acting as an intermediary and host for your containers. Nix can conjure arbitrary native development environments on a per-command or per-terminal basis, giving you all the perfo…
AFAIK, Nix does not work natively on Windows (you need to go through WSL), so it's not better in that regard.