dev: make binary target names cairo/starknet specific

[xJonathanLEI]

There are currently 8 binary targets in this repo:

• sierra-compile
• generate_syntax
• languageserver
• cairo-run
• formatter_cli
• starknet-compile
• starknet-sierra-compile
• cairo-compile

Out of which these 2 are not cairo/starknet specific (excluding generate_syntax since it looks like an internal tool only):

• languageserver
• formatter_cli

This can cause issues like name clashes when installed, and users will have to invoke the fomatter like:

$ formatter_cli

instead of something like cairo-fmt. I suggest we change them to:

• cairo-lsp
• cairo-fmt

respectively.

Ideally we should also change package names, not just for binary targets, but that would introduce a large amount of diffs that would likely interfere with other ongoing development efforts.

What do you think?

Update on 2022-11-26:

Here are the suggested new names:

Current Name	Available	Suggested New Name
casm	:x:	cairo-asm
compiler	:white_check_mark:	cairo-compiler
db_utils	:white_check_mark:	cairo-db-utils
debug	:white_check_mark:	cairo-debug
defs	:x:	cairo-defs
diagnostics	:x:	cairo-dxs
diagnostics_proc_macros	:white_check_mark:	cairo-dxs-macros
filesystem	:x:	cairo-fs
formatter	:white_check_mark:	cairo-fmt
languageserver	:white_check_mark:	cairo-lsp
lowering	:white_check_mark:	cairo-lowering
parser	:x:	cairo-parser
project	:x:	cairo-project
runner	:x:	cairo-runner
semantic	:x:	cairo-semantic
sierra	:x:	sierra-ir
sierra_gas	:white_check_mark:	sierra-gas
sierra_generator	:white_check_mark:	sierra-generator
sierra_to_casm	:white_check_mark:	sierra-compile
starknet	:x:	cairo-starknet
syntax	:white_check_mark:	cairo-syntax
utils	:x:	cairo-utils

[xJonathanLEI]

A better approach is to just move all binary targets to a dedicated package called cairo-cli, like what's done in foundry:

https://github.com/foundry-rs/foundry/blob/68714214c4aae6e337e6b2e40cf4de0d2de61f38/cli/Cargo.toml#L101_L109

(this makes installing all the binaries easy, but we still need to rename the binaries as suggested).

[xJonathanLEI]

To demo how such a refactor would look like, I've created a fork with the addition of a cairo-cli package containing all 7 CLI targets, in which you can just install all 7 binaries like this:

$ cargo install --locked --path cli
---- SNIP ----
   Installed package `cairo-cli v0.1.0` (executables `cairo-compile`, `cairo-fmt`, `cairo-lsp`, `cairo-run`, `sierra-compile`, `starknet-compile`, `starknet-sierra-compile`)

(Using symlinks in my fork to make it easier to rebase. In an actual refactor files should be moved instead)

Not submitting the unsolicited PR until I get confirmation from the team that this is actually desired.

[mkaput]

What's more, this also applies to crate names.

[xJonathanLEI]

What's more, this also applies to crate names.

Yeah if we eventually want to put this on crates.io then crate names should also be made cairo/starknet-speicifc.

Btw I've squatted the cairo-cli crate name just in case one day this project goes on crates.io.

[mkaput]

Yeah if we eventually want to put this on crates.io then crate names should also be made cairo/starknet-speicifc.

That's actually already an issue, because I have to use these super generic names in package manager code:

[spapinistarkware]

O think that's a good idea. Renaming crates and executables. I'd like to get such a PR. @orizi ? Wdyt?

One question - generate_syntax isn't supposed to be an exposed binary, it's just a utility for generating source code.

[orizi]

it sounds like a good idea.

[xJonathanLEI]

Thanks! So I guess the consensus here is to get this resolved early on to avoid breaking even more stuff later down the road.

Then I think the next logical step would be to determine which crates need renaming, and to what.

There are a total of 24 crates in this project. We already know that the syntax_codegen is just for internal codegen (won't get published on crates.io), so it doesn't need to be renamed.

On top of that, plugins seems to be only used in tests, so it won't get published either.

That should leave us with the following crates:

(Update: table moved to opening post for better visibility. Removing this one to avoid confusion.)

12 crate names are already taken on crates.io. We have to rename those if we want to eventually bring the whole thing on crates.io. Personally I think some names are way too generic even if available anyways.

Obviously I don't know the codebase good enough to come up with the best names. So this is totally just a suggestion. WDYT?

(I think we still need the new cairo-cli crate for making it easy to install the whole thing, but that one's easy to do once we get this resolved.)

[spapinistarkware]

I think every crate should be prefixed with cairo. I think we just didn't know these names correspond to package names on crates.io when we started writing.

[xJonathanLEI]

Got it. Thanks for the input. Would you like to simply prefix cairo- to all the current names?

My suggestions were based on this prefix-adding principle, while:

• applying abbreviation/simplification where applicable, which helps prevent overly long crate names (e.g. cairo-diagnostics-proc-macros)
• leaving the sierra-* crates unprefixed since they're already prefixed by sierra-
• using - instead of _

Please kindly let me know your preferences. Would love to push this forward and secure (squat) the crate names.

Btw I just moved the table from the comment to the opening post for better visibility.

[spapinistarkware]

This sounds good to me. Though, I don't like the dxs abbreviation. I don't mind having a long name, so I prefer diagnostics Other than that, would love to get a PR:)

[xJonathanLEI]

Sounds good! Will submit PR. Thanks!

[xJonathanLEI]

To make this PR manageable/reviewable and minimize the impact on other pending PRs, I will implement it as a script so that only the script needs to be reviewed. The PR itself can then be verified by running the script on the merge base to see if the exact same patch is generated. Pending PRs that are getting conflicts can simply have them resolved by running the script.