Allow publishing to crates with a publish = ["custom-registry"] set

[MarijnS95]

Fixes #18

Draft because this requires some testing, and figuring out how cargo publish behaves in various combinations, and how smart-release should follow:

• When publish = ["one", "two"] contains multiple registries?
• When --registry foo combines with publish = ["bar"], that crate is skipped;
• When --registry foo combines with unset publish, the crate is published to foo;
• When publish = ["foo"] is set without --registry CLI argument, the crate is automatically published to foo (or crates-io is publish is unset).

EDIT: Sorry for this really quick&dirty change, don't want it to be forgotten about but it's on a tangent of a tangent for me :)

[MarijnS95]

First test and this is already breaking, because smart-release doesn't see that the some crates have already been published to a custom registry. I assume only the --registry CLI argument currently tells it which registry to check.

EDIT: I'm not exactly seeing what currently makes smart-release load a different --registry and why it was working on re-runs before. Now even with --registry it's trying to publish the same crates again 😕
EDIT2: That could be git::change_since_last_release(), since I updated the Cargo.tomls with the publish = [] field since the latest tag 😅

[Byron]

Thanks for contributing.

First test and this is already breaking, because smart-release doesn't see that the some crates have already been published to a custom registry. I assume only the --registry CLI argument currently tells it which registry to check.

It uses crates-index-rs with the default Git index to figure out the latest published index. This is probably a dealbreaker for most private registries.

[MarijnS95]

Somehow it seems to figure it out. As edited above, I think it's because of making changes to crates that cause it to republish (as expected, but it was a bit annoying for my test-case).

[Byron]

The problem is that it won't be able to assure that the proposed crate version is more recent than the latest published one, and thus fail publishing.

[MarijnS95]

The problem is that it won't be able to assure that the proposed crate version is more recent than the latest published one, and thus fail publishing.

It doesn't fail, as pointed out above it seems to be looking at the git tags to understand whether the crate has already been published. This seems much less consistent/ideal than:

1. Check the registry;
2. Extract the git hash from .cargo-vcs-info.json;
3. Diff locally if the crate has changed since that hash?

---

The problem is more obvious in a different way though. fn wait_for_release() loops for 60 seconds trying to find the updated crate, and if it didn't, it continues without error/warning :(

---

Digging further with actually reading from my custom registry, it looks like rust-crates-index isn't up to this task at all :(. Created a tracking issue with my initial observations: frewsxcv/rust-crates-index#168

[Byron]

Sounds like a can of worms.

The version-tags are important for knowing the segments of commits which should contribute to the changelogs by the way.