Closed keepsimple1 closed 1 year ago
This is because
git-ref-format-macro
usesproc-macro
that AFAIK cannot mix into the same crate asradicle-git-ext
. I don't have a good idea to work around this limit at this point. Maybe in future?
Can you explain what the issues were?
This is because
git-ref-format-macro
usesproc-macro
that AFAIK cannot mix into the same crate asradicle-git-ext
. I don't have a good idea to work around this limit at this point. Maybe in future?Can you explain what the issues were?
There are two issues I encountered: (I'm a newbie in proc-macros).
src/
in this crate.After researching a bit more, I found that we can also solve item 2 by treating git-ref-format-macro
like an internal crate, and re-export all public macros in the parent crate. Such pattern is used in some common crates, like in thiserror
.
I've tried out a patch for moving git-ref-format
under radicle-git-ext
, but it is quite involved. I think it's better to do that in a separate PR. I will post that patch in a new PR after this PR is landed.
This is to address issue #114 .
git-commit
intoradicle-git-ext
crate. Copied:author.rs
commit.rs
headers.rs
t/src/commit.rs
git-commit
crate is not deleted because it's a published crate. Some users might depend on it.git-ref-format
crate for now.This is because
git-ref-format-macro
usesproc-macro
that AFAIK cannot mix into the same crate asradicle-git-ext
. I don't have a good idea to work around this limit at this point. Maybe in future?reference.rs
inracidle-git-ext
as it overlaps withgit-ref-format
. Also removedradicle-macros
andradicle-git-types
crates that used types inreference.rs
.Note that
radicle-macros
andradicle-git-types
are not published on crates.io, hence I think it's safe to remove them. Let me know otherwise.