pkgid output appears to no longer output package name even when the directory name and package name are the same

[colindean]

I've got a Makefile wrapping my Rust binary project that gets the name of the artifact using this:

cargo pkgid | cut -d '#' -f 2 | cut -d ':' -f 1

On my workstation, this returns the name of the package, same as what's as defined at package.name in Cargo.toml.

Recently, this started returning the version in Travis. I can't quite put my finger on when it started doing this, but I think it's with the release of 1.26 as our Travis builds are always against latest stable.

Confused, I debugged a bit.

On my mac:

~/Source/Arcadia/MACK/supervisor $ cargo pkgid
file:///Users/colin/Source/Arcadia/MACK/supervisor#mack-supervisor:0.1.0

On travis:

~/build/arcadia/mack-supervisor $ cargo pkgid
file:///home/travis/build/arcadia/mack-supervisor#0.1.0

Maybe it's a directory thing? If I change the name of the directory locally:

~/Source/Arcadia/MACK/mack-supervisor $ cargo pkgid
file:///Users/colin/Source/Arcadia/MACK/mack-supervisor#0.1.0

It appears that the name of the artifact no longer prints separately in the pkgid if the name of the binary and the directory name are the same. I believe this is a change in behavior.

My true need is "how I can I reliably get the name of the produced artifact?" and the snippet above was what was recommended in #cargo on IRC a few months ago…

[colindean]

I've asked about this over on the forums in case it's always behaved like this and the advice I got wasn't the 100% accurate answer for all cases.

https://users.rust-lang.org/t/what-is-the-best-way-to-get-the-name-of-the-binary-that-cargo-will-produce/17907

[ebkalderon]

Hello, @colindean! This appears to be completely expected behavior, as it's fully consistent with the formal grammar. It's honestly a wonder that you hadn't run into issues earlier with your existing parsing method. I guess you got lucky. 😄

The package ID from Travis refers to a package named mack-supervisor located at file:///home/travis/build/arcadia/mack-supervisor, while the package ID from your Mac refers to a package named mack-supervisor located at file:///Users/colin/Source/Arcadia/MACK/supervisor.

If you wanted to get the binary name consistently from a package ID, I'd say you could check the string from the end backwards and see if it runs into a # or : first. If it's a #, the text right before the # until it hits a / or the beginning of the string is the package name. If it's a :, the text right before the : until it hits a # is the package name.

Consider the following example:

file:///Users/colin/Source/Arcadia/MACK/supervisor#mack-supervisor:0.1.0
                                                  |______________||____|
                                                  3               2    1

1. Start from end of package ID and work right.
2. Found a `:`. The package name begins here.
3. Found a `#`. The package name ends here.

Here is another example using the same algorithm:

file:///home/travis/build/arcadia/mack-supervisor#0.1.0
                                 |______________||____|
                                 3               2    1

1. Start from end of package ID and work right.
2. Found a `#`. The package name begins here.
3. Found a `/`. The package name ends here.

Here is a bonus example where the package ID does not specify a source URL:

 mack-supervisor#0.1.0
|______________||____|
3               2    1

1. Start from end of package ID and work right.
2. Found a `#`. The package name begins here.
3. Reached the beginning of the string. The package name ends here.

Hope this helps.

[colindean]

Thanks for the thorough explanation, @ebkalderon.

I found another way to do it: use the cargo metadata command in conjunction with jq. I kinda dislike the added dependency on jq but it works.

cargo metadata --no-deps --format-version 1 | jq --raw-output '.packages[0] | [ .name, .version ] | join("-")'

The folks on the Rust user forum helped me figure it out in What is the best way to get the name of the binary that cargo will produce? .

I guess I'll close this since it's working as expected and seems not to have ever changed…