Package manifest name vs. directory name

[nyonson]

The rust-bitcoin/rust-bitcoin workspace has a convention to refer to packages using the directory name it lives in over the name specified in the package's manifest. So consensus_encoding instead of bitcoin-consensus-encoding. You can see this in stuff like the PR labels and the old CI config scripts. I am not sure of the exact reasons here, possibly to avoid all the bitcoin-* prefixes, quicker to find in the file system, but I would guess it is just easier when shell scripting things.

With cargo-rbmt, I have been preferring the manifest name instead of the directory. This matches cargo's --package arg which is used often by rbmt. It is also easier in rbmt to retrieve the package names under the hood with cargo metadata.

Now the question is if cargo-rbmt should force rust-bitcoin to change a bit and adopt more manifest name usage to simplify cargo-rbmt. One place I am considering now is how we store APIs under api/$PACKAGE/*, should package be the directory (like it is in rust-bitcoin) or the manifest name?

[tcharding]

Nice, new submission for most bike sheddable discussion! I'll start:

As far as api/ goes, I don't care, make it whatever is easier. I definitely do not want to make all the directories in the workspace start with bitcoin- that would just be painful IMO. And in the vernacular I'd prefer to continue referring to hashes and not bitcoin_hashes.

The cargo rbmt --package is ok, its bitten me before and will again but that's on me. I'd prefer it if there was alias' set up so we could type cargo rbmt -p hashes but its not a biggy because I can add my own shell alias'

[nyonson]

Nice, new submission for most bike sheddable discussion!

I'll accept my reward! On the plus side, I think this gives me enough of a rule to follow.

• Definitely not going to rename package directories.
• cargo-rbmt will prefer manifest names where possible.
• I can add Tobin's feature where if a --package isn't found with a manifest name, it can fallback to checking directory names.
• I might propose breaking up the api/ directory and putting it per-package (e.g. $PACKAGE/api/), this would require a few tweaks (like an exclude filter so the files aren't published, which can be enforced in the prerelease command), but would sidestep this issue.

[tcharding]

Sounds good to me. Probs wait till @apoelstra has a say.

[apoelstra]

All sounds good to me.

FWIW I wouldn't be too put out by renaming the directories. I agree we would rather not.