Closed afck closed 3 years ago
In this vein, there are still path = ../ff
and path = ../group
lines which prevent the library from building under the normal process, or when the cloned repos go out of sync, although the build works fine for anyone who clones all the crates together.
I think it might make sense to add this re-export to group
as well, since ff
and group
need to be kept internally in-sync as well. So you would then have imports like:
use bls12_381::{
pairing::{
group::{
ff::{Field, PrimeField},
Group,
},
Engine,
},
Bls12,
};
Hmm, I'm not sure the above tree strategy is ideal. e.g. for bls12_381
we have feature flags that enable group and pairing logic, so we couldn't rely on bls12_381::pairing::group::ff
to access ff
as pairing
might not be available. We'd actually need bls12_381::{ff, group, pairing}
re-exports, which would mean we'd be able to access ff
via bls12_381::{ff, group::ff, pairing::group::ff}
.
Alternatively we could explicitly prune the branches, e.g. at the bls12_381
level we could re-export everything except group::ff
from group
, and so on. That seems like it could easily miss things as underlying crates get updated though (since Rust can't do negative exports).
Thinking specifically about the traits, the tree strategy is fine. pairing
will always depend on both group
and ff
, so it makes sense to have pairing::group::ff
available. bls12_381
can conditionally depend on group
or pairing
, so if we want to re-export there, that's where we'd need to decide how to handle the duplicate re-exports.
Currently the user has to explicitly add the matching versions of the ff and group crates to their
Cargo.toml
, to use e.g.Field
orCurveAffine
. Would it make sense to re-export those frompairing
instead?That would avoid confusing errors (something like:
G1
doesn't implementCurveProjective
) whenever one dependency is upgraded without the other.