Custom crabc as dependency in Cargo.toml

[TCROC]

People are very excited about issues such as:

1. https://github.com/crablang/crab/issues/20
2. https://github.com/crablang/crab/issues/10
3. https://github.com/crablang/crab/issues/12
4. https://github.com/crablang/crab/issues/51

And many more ideas sprinkled throughout the issue boards and Discord server.

Even Graydon, the creator of Rust himself, had things he wanted to do differently: The Rust I Wanted Had No Future

I am a firm believer that in the world of software, we can actually "have our cake and eat it too". With the exception of meeting deadlines... so we just won't set those 😎

And I think Rust has proven this theory with its 0 cost abstractions.

So in order to accomplish this... Lets just add crabc as a dependency in Cargo.toml! It might look something like this (see the bottom [crabc]):

[package]
name = "super-cool-package"
version = "0.1.0" # I've accepted that 1.0 will almost never be a thing... so 0.1.0 will do :)
edition = "2021"

[dependencies]
# async stuffs
tokio = { version = "1", features = [ "macros" ] }
# serialization cause its cool
serde = "1.0.147"
serde_json = "1.0.87"
# This one seems to be popular lately
futures = "0.3.25"
# We are gonna do an internet!
http = "0.2.9"

[[bin]]
name = "bootstrap"
path = "src/main.rs"

# Here is the fun bit!
[crabc]
# Options: git | path | url
source_type = "git"

# This can point to a git repo,
# path on host machine (including binaries referenced from PATH environment variable), 
# or a crabc binary being hosted on the internet somewhere
source = "https://github.com/crablang/crab.git#experimental"

# Optional. Will default to using the bootstrapped crabc installed on host machine to 
# compile the experimental crabc. But if the project requires a more complex 
# build of a crabc compiler, then we can point to a build script.
script = "build_from_source.sh"

# Optional. Flags to compile crabc with. Is ignored if using a build script 
# as the build script should provide those. 
flags = [ "nightly", "crab-file-extension", "ternary-operator" ]

Why would we do this?

Currently if users want to use experimental features that aren't in master or nightly, they have to git clone <branch-with-cool-feature> and build from source. This is not a seamless experience and does not streamline the adoption of the most requested features such as the .crab file extension

Also, if a project requires a specific compiled version of crabc with a specific experimental feature, the author of the project has to be relied upon to provide that documentation. This would integrate that piece directly into the build process.

Potential downsides?

I was actually struggling to think of anything reasonable without feeling like I was grasping for straws. This normally leads me to believe I'm on to a good idea. I was able to think of one tho:

1. compiler conflicts 👀

If one user created a package that requires a specific crabc compiler with specific features enabled, it would make the package unusable in other projects. This sounds scary at first (I was actually concerned about this when it occurred to me) until you realize that this is nothing more than a standard dependency conflict. No different that 2 crabc crates conflicting with each other on dependencies. It will be up to the project author to maintain crates that have high compatibility within the crabc ecosystem by building it with features standardized in master. If they diverge with custom compilers, they will have to make note of such. Projects do that today such as rocket.rs v4 and lower with nightly features.

Potential implementations:

1. We could go the route of integrating this feature directly into crabgo. I personally like this idea best for crabgo as it becomes an "it just works" implementation which is always my favorite.
2. We could create a crabgo-crab and cargo-crab subcommand. I really like this idea for cargo. It can be hosted on crates.io and allow for cargo / rust users to point their Cargo.toml to crabc if they so desire! :) I think this would be HUGE for streamlining adoption. It will also help with interoperability between the rust and crab toolchains.

Note that this is a rough draft of an idea that came to me while taking a shower last night.

And another note: I'm not in love with the [crabc] syntax in the Cargo.toml above. We might be able to literally use the exact same syntax for [dependencies]. We can refine that in the comments. Just wanted to get my idea down and shared with you guys.

Do you love it? Hate it?

Is it engine to the rocket that CrabLang needs for taking off and going mainstream? 🚀

Or is it a rabid dog that needs to be taken out back and put down? 👀

Lets refine this thing together in the comments! :)

---

Edit:

I really like @HTG-YT 's proposed syntax here: https://discord.com/channels/1074804478651400303/1095989994033782814/1116011823733424128

source = { git = "https://github.com/crablang/crab.git", branch = "experimental" }

Would match with the current dependency syntax in Cargo.toml

---

Edit:

And additionally as noted by @HTG-YT , the source_type field would be rendered unnecessary! 🎉

# specifying a path to crabc
source = { path = "path/to/crabc/bin" }

# specifting a url to crabc
source = { url = "https://example.com/crabc/dist/some-crabc-here" }

[HTGAzureX1212]

Also to add on my proposal, (I just realized that) this would render the source_type field unnecessary.

This is due to the fact that you can simply change the source object:

# specifying a path to crabc
source = { path = "path/to/crabc/bin" }

# specifting a url to crabc
source = { url = "https://example.com/crabc/dist/some-crabc-here" }

[beepster4096]

I don't think its correct to put this in Cargo.toml. This really ought to be an extension of rust-toolchain.toml

[TCROC]

I agree. The more I've been thinking about it, the more I think we can accomplish this with custom build and run commands:

crabgo buildc crabgo runc

Which will look for a config pointing to a custom compiler. This will make interoperability between crab and rust easier I think.