varlink_derive = 10 not published

[cgwalters]

I am investigating varlink a bit more seriously for bootc (ref bootc-dev/bootc#522)

A lot of the examples commit the generated code, and the varlink_derive crate warns about IDEs not handling it. But that doesn't seem to be the case - completion works just fine with rust-analyzer nowadays for me using the derive path, and I definitely prefer not committing generated code unless necessary.

Anyways I was looking at this a bit more and I noticed that in the code it's version 10
yet https://crates.io/crates/varlink_derive/8.0.0 is the latest on crates.io.

[cgwalters]

Now the reason I stumbled into this is debugging why using varlink_derive fails to compile for me at all right now, I get:

   --> /var/home/walters/.cargo/registry/src/index.crates.io-6f17d22bba15001f/chainerror-0.4.3/src/lib.rs:493:1
    |
493 | impl<T: 'static + Display + Debug> Error for &ChainError<T> {
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: conflicting implementation in crate `core`:
            - impl<'a, T> std::error::Error for &'a T
              where T: std::error::Error, T: ?Sized;

For more information about this error, try `rustc --explain E0119`.
error: could not compile `chainerror` (lib) due to 1 previous error

And this seems to be a really ancient version, I have two different chainerror versions coming in this way.

$ cargo tree -i chainerror@0.4.3
chainerror v0.4.3
└── varlink_generator v8.0.0
    └── varlink_derive v8.0.0 (proc-macro)
        └── bootc-lib v1.1.2 (/var/home/walters/src/github/containers/bootc/lib)
            └── bootc v0.1.9 (/var/home/walters/src/github/containers/bootc/cli)
$ cargo tree -i chainerror@0.7.1
chainerror v0.7.1
└── varlink_parser v4.2.0
    └── varlink_generator v8.0.0
        └── varlink_derive v8.0.0 (proc-macro)
            └── bootc-lib v1.1.2 (/var/home/walters/src/github/containers/bootc/lib)
                └── bootc v0.1.9 (/var/home/walters/src/github/containers/bootc/cli)

And digging into that...do we really need chainerror at all vs the very, very widely used anyhow crate which has exactly that context method? (I make fairly heavy use of https://docs.rs/fn-error-context/latest/fn_error_context/ too)

[cgwalters]

@haraldh thanks for inviting me as a maintainer. I can't promise I'll do a lot here (and I'm still not sure I'm going actually use varlink, but I do plan to put in a little bit of work to give it a fair try).

On the mechanics, I think you've added at least me and zeeshan as committers, but I think you still are the sole person with access to publish the crates, is that correct? It's probably worth adding one or both of us there to reduce the "bus factor".

(One thing I've been meaning to set up on my projects is something like https://github.com/googleapis/release-please-action to automate publishing to crates.io from GHA)

[zeenix]

but I think you still are the sole person with access to publish the crates, is that correct? It's probably worth adding one or both of us there to reduce the "bus factor".

FWIW I already asked for that and Herald already added me as co-ownership on crates.io. I'd also be happy for you to be added there but I leave that for @haraldh to decide. :)

[haraldh]

release-please-action sounds like a good idea... let me know what you need for it

[cgwalters]

I don't need to be - I think two people is fine for now. As long as one of you can take care of doing an updated release for varlink_derive at a minimum (hmm do we need to bump the semver for #109 ?) I think that's probably enough for now.

[zeenix]

As long as one of you can take care of doing an updated release for varlink_derive at a minimum

I'll take a look later.

do we need to bump the semver for #109 ?

Need to take a closer look but if it's an external dep, then we do and if so, I'd rather we move to thiserror already if we're going to bump the semver.

[cgwalters]

I'll take a look later.

OK. I thought about this a bit more and basically: no urgency at all on this. I can use varlink from git for now and continue experimenting. It's enough to know it's maintained.

Need to take a closer look but if it's an external dep, then we do and if so, I'd rather we move to thiserror already if we're going to bump the semver.

👍

[zeenix]

I'll take a look later.

OK. I thought about this a bit more and basically: no urgency at all on this. I can use varlink from git for now and continue experimenting.

Cool, that's good to know cause I've a lot on my plate right now. I'd definitely plan to be a lot more active on this project in the future but for now I can help with the minimum at least: rolling out releases, reviewing PRs etc.

It's enough to know it's maintained.

Yeah, by you. 😆

---

P.S. I already have a WIP branch where I ported most of the code to thiserror already.