resholve VS devbox

I'm also not 100% on whether it answers the question, but I imagine you're thinking of https://github.com/abathur/resholve (doc in nixpkgs: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/misc/resholve/README.md)

I intend to eventually find some time to figure out how feasible it would be to use https://github.com/abathur/resholve or wrapper techniques to bolt basalt (and perhaps other bash PMs) on to the nix ecosystem and nix-package some of your libraries.

(I'd love to have this ability for https://github.com/abathur/resholve to reliably identify arguments to one command that are also external commands/programs that it will in turn exec. I can't imagine trying to start it until/unless I have any bright ideas about how that executable spec and a parser for it would work.)

In https://github.com/abathur/resholve/blob/master/default.nix and https://github.com/abathur/resholve/blob/master/shell.nix you can see one approach to extending that line of thought to the default.nix itself.

Completions have in general been of interest, though the shell-specific completions I've looked at so far were all too dynamic.

I'd forgotten all about Fig since I saw your launch post here last year, so thanks for reminder. (I don't think I had quite started to work on parsing specific external commands, yet. Was still focused on just identifying the likely presence of exec in the executables.)

Are you familiar with the parse code? Are you handling painful stuff like combined short flags with a trailing option? (If I ferreted out some of the more painful cases I've had to wrangle, I am curious if you'd have a gut sense of whether your approach handles it. Would you mind if I reach out? I am working on this for https://github.com/abathur/resholve)

@dloreto @robrich A little aside from the announcement, but since it seems like you both work on this I wanted to surface something that came up down in a subthread:

I'm curious if you attempted to support macOS by doing this with Nix's dockerTools and cross-compiling (there may be better sources, but it's at least hinted at in https://nix.dev/tutorials/building-and-running-docker-images...)? If so, I'm wondering where that failed or bogged down?

---

Background: I build a tool (https://github.com/abathur/resholve) for ~packaging Bash/Shell (i.e., for demanding all dependencies be present). The tool's technically agnostic, but I built it specifically to fix Shell packaging in Nix.

I think it could benefit a lot of other Shell projects, since one of Shell's big tribulations is dealing with heterogenous environments, but most Shell projects wouldn't see much reason to endure the pain of adopting Nix if they still had to support the heterogenous environments.

Much like you're doing here, I've entertained figuring out how to build a Nix-based packaging flow that can generate deployable standalone bundles or containers. It'd be a heavy way to bundle Shell, but I imagine some projects would take the tradeoff for predictability and reduced support load. But since it would need to take place within a Nix build, I'd need to cross-compile for it to work on macOS. Hoping you know if it's a dead-end or not :)

For a concrete example, I've been developing a tool (https://github.com/abathur/resholve) that can ~build/link Bash/Shell scripts--i.e., rewrite them with external executables converted to absolute paths. (This helps ensure dependencies are known, declared, present, and don't have to be on the global PATH for the script to execute cleanly.)

There's a devilish sub-problem, which is that any given executable can potentially exec arbitrary arguments. For now I handle this with a very crude automated binary/executable analysis that needs to be augmented by human source analysis. Deep multi-language source analysis wouldn't be very scalable, but I suspect fairly-standardized structural annotations could improve the results in a scalable way.

I have to imagine there are other applications of the same information.

I'm not 100% sure if you see the minimal PATH dependencies as a problem or not--so this may or may not help--but I develop https://github.com/abathur/resholve to make it easier to package Shell in Nix/nixpkgs by rewriting invocations of external dependencies in Shell scripts to absolute paths--and shunit2 is one of the Nix packages that I've updated to use resholve.

I came here to say this, too :)

But, of course, it still isn't a silver bullet...

1. You still have to have a sane PATH. A fair amount of the Nix install-related issues that get opened are PATH problems, and you can also run into problems with PATH in cron/launchd.

2. You still have to know what the script depends on. This can get tricky beyond small scripts you wrote yourself. (I write a tool for ~linking/resolving external dependencies in Shell scripts, https://github.com/abathur/resholve. As I've been working on converting some of nixpkgs' existing Shell packages to use it, I almost always find dependencies the initial packager missed.)

Check out resholve. https://github.com/abathur/resholve

Before I went on my Christmas vacation last year I wrote an article on how I use Nix in my Elm projects. At the time, I was pleased with my set up. However, not even a month would go by before my satisfaction was questioned. In early January, Carlo Ascani asked a question, on the Elm Discourse, about his Umbra project. I decided to explore his project and I soon discovered two files, devbox.json and devbox.lock, I had never seen before. This piqued my curiosity and I had to learn more. I followed the link to the Devbox website and feverishly read the docs. I... was... hooked. I was pleasantly surprised by its simplicity and it seemed to fit my use cases really well.

How does Flox compare to Devbox? https://github.com/jetpack-io/devbox

I've spent the last year managing all my packages with Devbox (https://github.com/jetpack-io/devbox).

Local dev, cloud dev, CI, production – all with the same config file. Fingers crossed my talk submission for PackagingCon gets accepted. It'd be awesome to share this new way of working with a wider audience.

> Now to figure out what a "flake" is…

Flake is a worthwhile addition to Nix that is worth learning. But like anything Nixian, it's not straightforward.

Have you checked out any of the tools that aim to simplify Nix experience? We built Devbox (https://github.com/jetpack-io/devbox) with this in mind.

Also devbox ( https://github.com/jetpack-io/devbox ) which is what this is for does not work on windows because of its Nix dependency.

For these reasons, I believe most developer environments should prioritize developer experience over fidelity. Tools like Containerized development environments and cloud emulators can strike the right balance and there’s no surprise that we see increased activity around devcontainers, and similar solutions.

Local first, cloud optional is the only way (IMHO) we're going to get people off their local laptop development setups.

We need to support local dev environments first, with the exact same config a developer can then move to the cloud.

See https://github.com/jetpack-io/devbox for how this can be achieved and https://www.mikenikles.com/blog/dev-environments-in-the-clou... for my thoughts after 3 years of working in this space.

If you like the properties of Nix, but find it confusing, you should check out Devbox! It simplifies the process of creating Nix-powered dev environments:

https://github.com/jetpack-io/devbox

As part of the work we've been doing with [devbox](https://github.com/jetpack-io/devbox), we needed a unit testing framework to test some of our nix code. Unfortunately we had some use cases where we did *not* want to introduce a dependency on `nixpkgs` (and therefore we couldn't use `runTests`).