## Summary

TSIA

## How was it tested?

## Summary

## How was it tested?

Signed-off-by: guangwu <[email protected]>

To check if nix daemon is running, Devbox runs:

	nix store info --json --store daemon

This fails on older versions of Nix for a couple reasons:

- Before Nix 2.19.0, `nix store info` was `nix store ping`.
- Before Nix 2.14.0, the `--json` flag wasn't supported.

Check for both of these versions when constructing the `nix store`
command so it works for Nix versions 2.12 - 2.21+.

Also add a `nix.VersionInfo.AtLeast` method and constants to make
checking for supported major Nix versions easier.

Tested by running the `nix store` commands on all supported Nix
versions.

## Summary

This changes how `installNixPackagesToStore` calls `nix.Build` so that
it installs all installables in same nix command.

It does this by grouping all installables into two groups, one for
allow-insecure and other for default and runs `build` on both groups (if
not empty)

I was able to remove `packageInstallErrorHandler` because it is already
called in `packagesToInstallInStore` so we will never actually try to
build something that can't build on the system, or if it requires
`--allow-insecure` we will notice it then.

This does change our segment logging to group packages together for
install times, so we will need to do some more work on the metrics side
to determine slow packages.

## How was it tested?

* Installed multiple packages not present in my nix store at once,
including a combination of secure and insecure ones.
* Tried to install something that doesn't build on my system, saw
correct error message

## Perf test

Anecdotal test:

Using the following
<img width="257" alt="image"
src="https://github.com/jetify-com/devbox/assets/544948/8b1ab39c-7a1b-40d3-ab5a-516cde3b1525">


Before 
<img width="261" alt="image"
src="https://github.com/jetify-com/devbox/assets/544948/ce397f59-1eaf-41dc-8256-6306f36e596b">

After 
<img width="293" alt="image"
src="https://github.com/jetify-com/devbox/assets/544948/55ed3214-ff1d-4115-b767-7ad5d29dedd3">

## Summary

Bumps to v1.5.0

Note: Because process-compose flake is not in any cache installing a new
version can be pretty slow (it has to build which means it has to
download dependencies in order to build). A few solutions:

* We could use nixpkgs (which lags the repo version by a few versions)
* We could use runx to install it (not nix, but it gets the latest
version)
* We could store in our own cache.

## How was it tested?

Tested running services on a few examples.

## Summary

If store path exists locally, we know we can use that store path in
`fetchClosure`. This helps speed up almost any operation where state is
not up to date and we need to check if some store path is in cache.

## How was it tested?

* added print statement

`devbox run echo 5`

…2044)

## Summary

Current `devbox search` UI only shows the 10 newest versions for a
package, unless the developer runs the command with `--show-all`. With
the current presentation, this may confuse developers by making it seem
like only 10 versions are available at all.

This pr Adds a `...` at the end to indicate that more versions are
available. For example:

```
Found 8+ results for "python":

* python  (3.13.0a6, 3.13.0a5, 3.13.0a3, 3.13.0a2, 3.13.0a1, 3.12.3, 3.12.2, 3.12.1, 3.12.0, 3.12.0rc3 ...)
* python-cosmopolitan  (3.6.14)
* python-launcher  (1.0.0)
* python-qt  (3.5.2, 3.5.1, 3.4.2, 3.3.0, 3.2)
* python-swiftclient  (4.2.0, 4.1.0, 4.0.0, 3.13.1, 3.13.0, 3.12.0)
* python-language-server  (2022-02-18, 2021-09-08, 2021-05-20, 2020-10-08, 2020-06-19, 2020-04-24)
* python-matter-server  (5.10.0, 5.9.0, 5.8.1, 5.8.0, 5.7.0b2, 5.5.3, 5.1.1, 5.0.3, 4.0.2, 4.0.1 ...)
* python-full  (3.13.0a6, 3.13.0a5, 3.13.0a3, 3.13.0a2, 3.13.0a1, 3.12.3, 3.12.2, 3.12.1, 3.12.0, 3.11.9 ...)

Warning: Showing top 10 results and truncated versions. Use --show-all to show all.
```

## How was it tested?

Debugged locally, tested with `go` and `python`
Also verified that the ellipses don't appear when the `--show-all` flag
is set

)

## Summary

Add documentation for RabbitMQ + MongoD

## How was it tested?

Localhost + `npm run build` to test broken links

## Summary

TSIA

## How was it tested?

localhost + npm run build

…2050)

Reverts #2042

#2042 introduced a bug where adding non-cached packages
would fail to add them to the flake on the first attempt. (it would
succeed on subsequent attempts after the package is already in the
store).

The root cause is that `fetchNarInfoStatus` gets called twice per
package (even though we cache it and we're not supposed to call it
twice). The first call returns `false` because the package is not
cached. The second call returns `true` because the package is already in
store. This discrepancy essentially causes the package not to appear on
the flake at all. When updating state again, the package is already in
the nix store so both `fetchNarInfoStatus` calls return true.

I think reverting this is best immediate course of action. In follow up
we should fix `fetchNarInfoStatus` so it only gets called once (it will
improve performance and is more correct).

Later on we can think of better way to do #2042. The
current implementation is a bit fragile and not 100% consistent with the
initial intention of the function, so I'm concerned it can lead to more
bugs in the future.