Use features to improve build times and reach more users?

[gilescope]

On a fairly fast macbook pro (4core/8threads) it compiles in 3m 25s. For enterprise hardware with many levels of virus checkers, it takes longer. I wouldn't like to comment on how long it might take on a raspberry pi.

Is everything in cargo-make essential? Do all users use duckscript for example? I'd love to use cargo-make but currently I stand no chance of selling it to the team due to how much it pulls in.

If there were options to not include all the batteries, there's many more projects that would consider using cargo-make.

[sagiegurari]

why not just used the precompiled binaries?

[gilescope]

Sounds good, but there's few win/linux package managers (conda being a notable exception).

cargo precompiled-install isn't a thing yet, though I would think for tier-1 platforms that's something that would be nice but cargo install x works well because it's doesn't use binaries so doesn't hit many of the issues with downloading binaries in corporate environments.

[sagiegurari]

wait, i mean that the releases page on github has precompiled binaries available for download for mac, windows and linux. so they can download from there. no need to run any cargo command or use some package manager.

i even have precompiled arm linux available.

[gilescope]

Oh they got that covered. All github release downloads blocked. Sigh, that's just what companies do... (Edit: This is sounding like I'm in a very special situation, but I've been working in these kind of environments for 20 years so I think it's not that uncommon for some industries)

[sagiegurari]

breaking it up with rust features is just not going to work well for cargo make as much of the code is also in scripts.
you asked about duckscript for example, so there are core tasks that use it. and if i disable it, it will compile but fail in runtime. so I don't want to go there.

usually you install a build tool only once and upgrade only if you must. so its a one time bump.

another option is to install once and maybe upload the binary into your company binary artifact repository (artifactory, nexus so on....)

[MartinKavik]

I've just found a tool that maybe would help with it: https://crates.io/crates/cargo-quickinstall (I haven't tried it yet)

Or we can draw an inspiration from it and create a super simple installation crate - e.g. cargo-make-installer. Users would install cargo-make with a cross-platform one-liner like cargo install cargo-make-installer && cargo-make-installer. Or just cargo install cargo-make-installer if it makes sense and if there is a way to run a post-install scripts or something like build.rs is enough.
cargo-make-install would just download the latest cargo-make binaries.

[sagiegurari]

@MartinKavik thanks for the idea. i was actually reading about it few days ago and found it interesting.
i actually thought about using it to increase installation speed of crates by cargo-make (right now i use cargo install or rustup, why not also support that if its fast and maintained), but using it to also install cargo-make faster wasn't on my mind and its a good idea.

at the moment, i'm not sure how mature it is, but if you want to investigate it and maybe start a discussion that will lead to a PR it would greatly help :)

[MartinKavik]

I've created the issue in cargo-quickinstall repo with an idea and to get some info.

When I try to use it - cargo quickinstall cargo-make, it returns:

$ cargo quickinstall cargo-make
Could not find a pre-built package for cargo-make 0.32.14 on x86_64-pc-windows-msvc.
We have reported your installation request, so it should be built soon.
Falling back to `cargo install`.
    Updating crates.io index
     Ignored package `cargo-make v0.32.14` is already installed, use --force to override

So it seems to be at least safe to use already thanks to the fallback to standard cargo install even so the build pipeline probably run only once a day now and perhaps doesn't build all requested packages.

[alsuren]

even so the build pipeline probably run only once a day now and perhaps doesn't build all requested packages.

The build pipeline builds a single package per hour. Most of the time, there's only one or two packages in the build queue, so it should be built soon. I've not been paying attention to quickinstall recently, so it looks like I've got some broken packages floating around in my build queue (I should really automate the process of cleaning those up).

If anyone can think of a design for triggering a build on-demand and waiting for it to finish building, please open an issue, and I will put it at the top of my backlog (https://github.com/alsuren/cargo-quickinstall/projects/1).

[dbanty]

I'm pretty sure this project is available via cargo-quickinstall now—though I've been using cargo-binstall to get at it. I'm not sure about resolution priority, but you could support the cargo-binstall format directly to not have to wait on cargo-quickinstall's build pipeline.

[gilescope]

Maybe it’s just me but the more deps involved, the greater the security risk of a supply chain attack. Cargo Quickinstall does seem like a good way to cut the build times though.

…

On Sun, 31 Jul 2022 at 01:52, Dylan Anthony ***@***.***> wrote: I'm pretty sure this project is available via cargo-quickinstall now—though I've been using cargo-binstall <https://github.com/ryankurte/cargo-binstall> to get at it. I'm not sure about resolution priority, but you could support the cargo-binstall format directly to not have to wait on cargo-quickinstall's build pipeline. — Reply to this email directly, view it on GitHub <#442 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGEJCAQRHRZJL33KD5RQRDVWXE45ANCNFSM4PKGPHYQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>