-
search.nixos.org also includes flakes that people PR into the index via GitHub at https://github.com/NixOS/nixos-search/issues
ps: $ nix search exists via experimental flags https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3...
-
InfluxDB
InfluxDB – Built for High-Performance Time Series Workloads. InfluxDB 3 OSS is now GA. Transform, enrich, and act on time series data directly in the database. Automate critical tasks and eliminate the need to move data externally. Download now.
-
or https://search.nixos.org
if folks want a easy (and good way) to get up and running in the nix ecosystem w/services ala replace docker compose then https://devenv.sh is the shizz
-
- you may want to search from the command line
`nix search` is a cruel joke which doesn't allow searching by the name/program that would be installed, only package name, and requires a flake name every time. Absolutely terrible interface.
My tool is a single-install binary that performs fast and accurate search to help you find the right package name to install a given binary. I don't understand how after years of using other package managers anyone could want a search tool that does anything other than this by default.
For more details on why this exists, check out https://github.com/peterldowns/nix-search-cli#motivation
-
> If only there were a Buck2 and Nix hybrid
You'll be interested in https://github.com/thoughtpolice/buck2-nix
-
Dang this is cool! I get why replit went so heavy on nix but I also feel like it must have a cost for them — nix is hard to learn, especially for folks new to development which I know makes up a lot of replits customer base.
We built a solution to the same problem with a similar approach[1], but that just snapshots any old files instead of doing nix derivations. Nix couples the build process to the content-addressability of the output, which works great if you want to put all the effort in to deterministic builds. We just read files like git does which works great for non-deterministic processes like npm install (tragically).
I like the idea of the Big Disk style of attaching a content addressable cache, but in our experiments we still found the network latency to the attached disk too high when reading file by file, like when booting a node app, so we’re caching a much smaller amount on a local SSD for each prod server. Maybe replit isn’t as sensitive to read perf from the cache layer, or they have fancy local per-node read through caching within the overlay setup? Regardless, cool!!
[1]: https://github.com/gadget-inc/dateilager
-
I got u
https://github.com/NixOS/nix/issues/6316
-
> Afterwards, Flakes itself and its CLI components can be stabilized. The final design of Flakes will also require another RFC.
That seems like Flakes are still quite a ways away.
[1] - https://github.com/NixOS/rfcs/pull/136
First, the non-Flakes CLI wll be stabilized, in phases. -
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
I believe the Hackage.nix library [1] has a solution to this problem, specifically for Haskell packages.
The `text` package [2] has many major, minor, and fix versions. Many of these versions are still required by projects. However, the current Nix Packages only has one version [3], and maybe a second version under a different name.
Hackage.nix will provide any version of `text` published on Hackage.
One downside is that `text` is not pulled from Nix Packages. The project's specific version of `text` must be cached elsewhere, or built from source. So it is slower.
[1] https://github.com/input-output-hk/hackage.nix
-
