Alternative Rust Build Tooling

[atm1150]

Related to an existing integration?

Yes

Existing integration

CommunityToolkit.Aspire.Hosting.Rust

Overview

Currently the rust integration requires that the build tool used is cargo but also the user is forced to use the "run" command as well. For the vast majority of rust programs this is more than sufficient but there are use cases that either use alternative build tools or sometimes people extend the cargo build tool to allow for additional functionality during development. Below are links to the trunk build tool which is meant for CSR style WASM workloads while the other is an extension to cargo for the Leptos framework that is used in their SSR and hybrid deployment models.

https://trunkrs.dev/
https://github.com/leptos-rs/cargo-leptos?tab=readme-ov-file

I personally believe it is beneficial to refactor the current "AddRustApp" method to allow for these alternative tools as this will allow for a single central place to integrate rust code into Aspire but also to prevent integration creep from every rust framework in existence having to add its own integration rather than working through the existing rust code. It is my opinion that the current code can be refactored to allow for alternative build tools/commands while not creating any breaking changes. My proposed refactor includes the use of optional parameters to ensure that current code not only does not break, but also maintains the default setting of "cargo run" being the preferred tooling process which even if a full rewrite was done I would absolutely agree that such should be the default setting to prevent users from shooting themselves in the foot. Below I will show some example pictures of my code changes to see if the maintainers here agree with my changes or can point out special cases that would become broken due to my code so I can attempt to find another solution. I will also provide a link to my fork of this branch

https://github.com/atm1150/Aspire/tree/leptos-integration

The two main changes in this fork are in the RustAppExecutableResource and in its AddRustApp extension method. The executable resource is changed to allow an optional param that will be passed to the ExecutableResource base class constructor rather requiring cargo alone. The executable resource file also contains a new RustBuildOptions class that is optionally passed into the AddRustApp extension method and if one is passed into it then the default tooling config of "cargo run" is replaced with the RustBuildOptions values.

Usage example

Breaking change?

I'm not sure

Alternatives

The best alternative as I see is to have a full and singular integration for each separate rust framework or build process that does not utilize the default "cargo run" and I believe this is a disadvantage over time as it creates further integrations that must be maintained or it requires that all people not using "cargo run" must always write their rust based resources from scratch.

Additional context

No response

Help us help you

Yes, I'd like to be assigned to work on this item

[aaronpowell]

Would it make sense to use the current API surface, or should there be another method that indicates an alternative way you want to create/run a rust app?

I'm very much not a Rust dev, and the integration is obviously very basic in the current design, so if there are ways to improve it to fit better into workflows that incorporate Rust into an Aspire app, then we're very welcome to having the contributions.

[atm1150]

I program in c# professionally and started rust this past summer in my hobby projects so there are probably better people than I to comment on the absolute best ways to integrate rust.

Having a 2nd method for alternative build tooling may be a better option than combining all integrations into one method. The current implementation can be used as the default and another method can be made that does most of the same but it requires the command to be passed in and it can have a required args param as the new method would not automatically supply the "run" argument to the "cargo" command.

My personal opinion is that the best way to integrate rust would not involve separate methods/resources for every framework or workload in the rust ecosystem as that could potentially create a ton of maintenance work down the line. A default option for rust apps with predefined defaults and a 2nd option allowing greater customization seems like a great way to structure it. Again I am a hobbyist in rust though so input from someone more experienced would be greatly appreciated

[Odonno]

I don't really know what we can do here. I myself am a strong user of bacon to have a decent watch experience and so I am relatively happy with the AddExecutable extension method for the moment.

The only missing (minor) bit would be to bring extension methods for .WithIconName() for each language so that we can easily customize the icon per the appropriate language (an Executable of bacon would display the Rust icon, an Executable of electron app would display the JS icon, for example purposes). Best option would be to bring this extension method with the associate package but a Aspire.IconExtensions (or something close) can also be a good idea.

[atm1150]

@Odonno Do you see any technical issues with my suggestion or aarons suggestion of simply creating a new method for the api surface for advanced use cases? I will freely admit to only being a hobbyist with rust and would love to hear feedback from someone more knowledgeable to ensure that any new surface added to the api isn't inherently flawed and needs future fixing.

[Odonno]

This is indeed an interesting POV @atm1150. If we want to improve the experience for Rust developers, I would probably go this way:

• Keep AddRustApp using the cargo run command
• Add a AddRustExecutable by giving the name of the binary to execute
  • with a following extension method named WithCargoInstaller(b = true, locked = false, features = string.Empty)

This way you don't break the existing codebase and you add the possibility to execute any cargo binary. For the my use case, it could look like:

var api = builder
    .AddRustExecutable("api", "bacon", "./apps/api", ["main", "--headless"])
    .WithCargoInstaller(b: true, locked: true, features: "sound")
    .WithHttpEndpoint(env: "PORT")
    .WithHttpHealthCheck("/health")

I mimicked WithCargoInstaller from WithBunInstaller both being a compiler/bundler and a package manager, I think that should suit the need.

What do you think?

[aaronpowell]

Declaring my complete naivety on Rust.

Could we model it similar to how the Python and Node integrations work with Aspire 13, where you have a "base" that does the most common one:

builder.AddJavaScriptApp("js-api", ...);

This becomes npm run dev (for local dev). But if you want to use something yarn or pnpm instead of npm, you add the .WithYarn extension method.

Could that be applied to Rust? There is a base method that just adds a most basic Rust app launcher, but then there are methods to override to use bacon as the executable?

[atm1150]

@aaronpowell I think the issue with that is that you would essentially just be writing a an executable resource behind the scenes that overwrites everything in the builder.AddRustApp("api", ...)

The image below shows the current executable resource and as you can see it is hard coupled to cargo. Any implementation we do either needs to refactor this resource to allow for things other than cargo to be passed in, it needs a separate resource for other use cases, or it just uses AddExecutable behind the scenes. Since cargo is so dominant I'm not sure if having extension methods for different build tools is a good idea because I can't really say if any have the traction to ever have their own dedicated method. I briefly looked at bacon which was brought up and that seemed like something that might be worth its own extension method purely for QoL aspects of it. I think the only thing I mentioned in my examples that might be worth its own extension method would be trunk as its meant to work as a WASM code bundler and local dev server for supplying the WASM content in development.

I havent had a chance to look over the code @Odonno mentions above but from an initial glance it does look clean and as a separate method it would give the opportunity to write specific code geared towards a generic build tool depending on how its written

[aaronpowell]

Aspire 13 introduced a new method that allows you to change the command for the executable resource, it's what the yarn and uv extensions do.

[atm1150]

@aaronpowell I was not aware that was added into aspire so most, if not all, of my last comment can be safely ignored.

I've also now had the chance to look over the bun code @Odonno mentioned and I have a follow up question. I'm assuming your parameter named "b" is meant to represent build/install of the underlying tooling, aka trunk, bacon, or cargo leptos but if not could you provide the specifics as to what it is meant to do?

If I'm correctly understanding Odonno's code sample then I would prefer that as a generic api surface for adding non standard rust build tooling over my own suggestion that simply passed optional BuildOptions into the existing AddRustApp.

I think between the options Aaron and Odonno mentioned,the dilemma comes down to type safety vs the size of the api surface. I think it is fair to say that in a vacuum, most rust users would probably prefer to have strong type safety when interacting with the aspire code but my worry is that cargo is simply so dominant that adding individual extension methods per build tool just may not be worth it as I can't guarantee there will be an audience large enough to warrant the maintenance. Odonno's code seems to be a good way to have an open ended api with good customization options. If the individual extension methods per build tool are the better way to make the code fit the aspire code style then I would recommend limiting them to build tools that are very generic like trunk or bacon. While I do personally use cargo leptos I think it simply doesn't provide enough utility to warrant its own extension that must be maintained and unless it, or another rust front end framework like dioxus, become more dominant then I think its fair to say users may just need to write their own resource.

Overall, I think one of you has more rust knowledge and the other is an Aspire maintainer so I'm cool with whatever the two of you decide is best.

[Odonno]

@atm1150 In my example, b stands for binstall, see https://github.com/cargo-bins/cargo-binstall. It is an alternative cargo installer using pre-compiled binaries. So, binstall, locked and features seems like the necessary set of arguments that one can expect for installing an additional tool like bacon or trunk, if not already installed. I did not think of that but we may also consider these arguments:

• an optional version (being latest by default)
• a --git url, if the only possible option is to install a tool from a remote git repository
• a --path, if the only possible option is to install a local tool only accessible from the same filesystem

[atm1150]

@Odonno These all seem like good params to me. It allows for specifying feature sets, an option for binstall so users dont have to build locally after getting source if the artifact exists, a version param to specify which version to grab, and the two fallback options for a git repo or a local repo.

In the event that someone puts in a value for local and git would we simply have the code determine a priority and then upon failure go to the next option provided? Id think if local is specified that might be highest priority and then try the others if needed

[Odonno]

I'd let cargo deal with it. I have the feeling it would panic.

[atm1150]

That sounds good to me.

I guess now all thats left is to make a final decision on the best path to take. Either an extension method per resource or odonnos idea. Im fine with either option.

Once we determine which path to go down I can try to write up some code whenever I have free time or we can go over implementation specifics if that's preferred