-
Notifications
You must be signed in to change notification settings - Fork 233
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Supporting pure build toolchains #732
Comments
Nope. However, IIRC trunk has a nixos package, and an |
Indeed I used the nix package to run trunk, and I will that package as a build dependency to build an application. For context, Nix builds are only done for deployment. The goal is to complete every build step in a sandbox using only upstream outputs or resources that can be content hashed. Cargo Cargo is one piece. Broadly, any steps that might try to access the network will need some treatment. I don't really use SASS etc, so maybe you can help me out at identifying other potential sources of network access used by To make the cargo step pure, as far as Trunk is concerned, I only need to specify the path where Trunk can find my cargo outputs and proceed with bindgen and so on. I will complete the cargo build independently before handing off to Trunk. This probably means I just use an option to delegate part of the cargo pipeline. In case you are curious about the delegation, purifying cargo builds to succeed in a sandbox can be broken into three steps:
All of the Nix tools for building a Rust binary use variations of steps 1-3 and varying degrees of composition of steps (step 3). |
I don't know about nix, so I can't help much there. But to my understanding, you would need to pull in all inputs (tools and source) through some trusted mechanism. May the by nix or just trusting your local source. So I guess, like a container, you would need to assemble some build environment with nix, which has all the tools required pre-populated. And then run After that, just provide that environment your own sources, as well as the vendored ones. cargo should take care of the rest. So I think this should already be possible. |
Ping me if anyone looks for Nix support. I have a pretty good idea of the scope of the work needed. It's minor surgery. However, I decided to go full stack for now. Since I have in independent API server, I may go back to Trunk. I was just interested in getting SSR for at least the client-independent rendering to do fine with SEO and low / no javascript. |
I would love to hear if you identified a fix, I am currently struggling with deploying and app in nix via trunk due to the runtime deps it wants to download, and it fails to even search your path if you provide them in a sane manner.
|
And to make things worse if you let it download bins they don't run as expected
|
Looks like there's a hint:
One aspect of trunk is to manage the required CLIs for you. If you opt-out of this, you need to take care of this yourself. And if you want to use it, trunk can only do this for environments for which the dependencies/tools support it. It looks like wasm-bindgen released a binary which doesn't run on nixos. I wouldn't see this as an issue of trunk though. Judging from the error message, it looks like you're running an older version of trunk. Could you run |
I am not sure what needs to be done here. It feels more like a discussion. So maybe this should be transformed into one. |
Writing this relatively late for me, so expect inaccuracies.
In order to ensure reproducibility and avoid unidentified supply chain surface area, Nix and Guix etc seek to build from within a sandbox.
To accomplish this, the network access for dependencies happens separately from any build and cargo is directed to the location of these pre-fetched dependencies and made to succeed somewhat painstakingly.
Since providing and using the dependencies for a Rust build output are pretty tightly related, it makes sense to output the wasm and then hand it to trunk to complete the steps of running bindgen and bundling.
Have you seen any of this done or considered it yet?
The text was updated successfully, but these errors were encountered: