[Feature] Create a Prelude and Feature Flag for Rustix

[andar1an]

With Single file Rust files, specifically to do with scripting leveraging Cargo-Script, or an alternative Rust-Script for example:

• https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#script
• Tracking Issue for cargo-script RFC 3424 rust-lang/cargo#12207
• https://github.com/fornwall/rust-script

could there be value in creating a prelude and a feature flag that could bring a collection of names and common features into scope for convenience while creating scripts?

I am just starting to play with Rustix, so I apologize if this is something that is not feasible due to the vast scope of Rustix, but if it is feasible, it could make using Rustix in single file rust scripts much more ergonomic.

[sunfishcode]

I'm generally under the impression that rustix is too low-level to be convenient for writing scripts, most of the time. Also, rustix has a lot of features and each user uses different features, so there isn't an obvious set of features to include in a prelude. That said, if you have a clear view of what such a prelude should include, I'd be open to considering it.

[andar1an]

Thanks Dan, I am still trying to fit Rustix into my mental model, and am trying to find the best use case for rust scripts, but that was the wrong reason for a prelude. Appreciate the response, and help working though the thought.

I think the use of the word "script" was a bad choice, while a single file rust utility is akin to a script, it does compile to a binary, and I am still trying to find the best way to word these thoughts. I can refer to them as single file utility maybe.

For a small single file utility, the scope would be too small and additional features would be just wasted space, even if insignificant.

Could there be a reason for a general prelude more akin to "all-features"? Having that low level access of directly using linux sys-calls as backend could enable writing ones own utilities easily without relying on external libraries like gnu-utils or busybox. Especially if one wants to limit C exposure in code-base.

Whether musl, glibc, doesn't really matter if one writes with rustix with sys-call backend? I guess the only reason to have a prelude in hind-sight would be for more monolithic utilities akin to Busybox, and potentially more complex single scope utilities like iwd?

Could a prelude be relevant to Rust OS development? Rustix seems interesting there also, because it could enable portability with OS's written in rust and integrating with new Wayland compositors and Rust widget and gui systems exclusive of standard C libraries and packages as long as they are somewhat POSIX compliant potentially like Redox or Asternias?

[sunfishcode]

It doesn't seem like you need a prelude here. A prelude is just a big pub use that creates aliases for a bunch of things that are already public, in a single place. It doesn't enable any new use cases; it's just slightly more convenient if you use those specific things a lot.

If you want to do Rust OS development or Wayland compositors or GUI systems or scripts or anything else, you can do all that without a prelude.

If you happen to find yourself frequently typing use rustix::%STUFF%; with the same value of %STUFF% a lot, then a prelude could make that slightly more convenient. That's all preludes do.

[andar1an]

I also think preludes are nice for discovery as well, they make it easier to access function within a crate without needing to explicitly bring in features.

I have found preludes to be a good experience when initially trying a crate because it could limit the front loaded learning before scoping ergonomics, but that can also have downsides.

I can close issue now, thanks again.