-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
0.19 bitvec break by 1.2 funty, causes nom 6.1 to fail to compile #3
Comments
It looks like My
Build error: (click to expand)
|
Just my 2 cents. It may be a good idea to yank funty 1.2 and re-release it as 2.0 due to the break changes. |
Actually it is not a good idea to glob-import stuff I think, as with this any accidental name collision can become a breaking change. I believe it's a better idea to remove the glob-import on bitvec side. |
This is how [dependencies.funty]
version = "1"
default-features = false As a temporary workaround you can force to use version [dependencies]
funty="=1.1.0" |
…vent compile errors The bitvec crate does note compile any longer with the new released version of funty. As a temporary fix the version is pinned to the previous version that worked normally as suggested in the github issue: ferrilab/funty#3
The problem is as follows, pub trait BitMemory: IsUnsigned + seal::Sealed {
const BITS: u8 = mem::size_of::<Self>() as u8 * 8;
const INDX: u8 = Self::BITS.trailing_zeros() as u8;
const MASK: u8 = Self::BITS - 1;
}
Because So... could |
|
Technically yes, but this isn't about that - albeit I strongly believe |
nom => bitvec => funty 1.2.0 is currently not building due to an ambiguous associated constant. See ferrilab/funty#3.
This causes nom to be pulled in, which currently causes the CI error and build conflict between `funty` and `bitvec`: ferrilab/funty#3 We don't need the feature in this scenario anyway.
For completeness, this bug breaks my crate "tp-note" also:
The workaround "Downgrade
|
This is a temporary workaround of this downstream bug: <ferrilab/funty#3> Can be reverted when fixed there.
This causes nom to be pulled in, which currently causes the CI error and build conflict between `funty` and `bitvec`: ferrilab/funty#3 We don't need the feature in this scenario anyway.
nom 6.1.1 is released with a fix for this: https://crates.io/crates/nom/6.1.1 |
It is used for release builds. This prevents CI build suddenly breaking because of breaking changes in dependencies of dependencies (see ferrilab/funty#3)
There was a conflict between bitvec and a dependency of it (funty) that caused a build failure. See: - ferrilab/bitvec#105 - ferrilab/funty#3 Due to semver, when importing parity-scale-codec as a library adn resolving bitvec 0.20.1 dependencies, funty 0.12 is pulled, which causes the aforementioned build failure. I believe this is not happening when testing parity-scale-codec itself because Cargo.lock pins funty to 1.1.0, but when importing parity-scale-codec from another crate, this pinning is sometimes not possible. Bumping bitvec to 0.22.3 solves this issue, as it is compatible with funty 0.12.
There was a conflict between bitvec and a dependency of it (funty) that caused a build failure. See: - ferrilab/bitvec#105 - ferrilab/funty#3 Due to semver, when importing parity-scale-codec as a library and resolving bitvec 0.20.1 dependencies, funty 0.12 is pulled, which causes the aforementioned build failure. I believe this is not happening when testing parity-scale-codec itself because Cargo.lock pins funty to 1.1.0, but when importing parity-scale-codec from another crate, this pinning is sometimes not possible. Bumping bitvec to 0.22.3 solves this issue, as it is compatible with funty 0.12.
There was a conflict between bitvec and a dependency of it (funty) that caused a build failure. See: - ferrilab/bitvec#105 - ferrilab/funty#3 Due to semver, when importing parity-scale-codec as a library and resolving bitvec 0.20.1 dependencies, funty 0.12 is pulled, which causes the aforementioned build failure. I believe this is not happening when testing parity-scale-codec itself because Cargo.lock pins funty to 1.1.0, but when importing parity-scale-codec from another crate, this pinning is sometimes not possible. Bumping bitvec to 0.22.3 solves this issue, as it is compatible with funty 0.12.
There was a conflict between bitvec and a dependency of it (funty) that caused a build failure. See: - ferrilab/bitvec#105 - ferrilab/funty#3 Due to semver, when importing parity-scale-codec as a library and resolving bitvec 0.20.1 dependencies, funty 0.12 is pulled, which causes the aforementioned build failure. I believe this is not happening when testing parity-scale-codec itself because Cargo.lock pins funty to 1.1.0, but when importing parity-scale-codec from another crate, this pinning is sometimes not possible. Bumping bitvec to 0.22.3 solves this issue, as it is compatible with funty 0.12.
friendly ping @myrrlyn, is there any chance to yank |
I apologize for the silence. This has been quite the year, and I've honestly neglected my GitHub notifications.
|
Fantastic! 🎉 Quick question: as you plan to yank all |
thanks a lot to have published the |
Now that |
Hello @myrrlyn , would you consider to yank |
bumping dependency version needed to resolve ferrilab/funty#3
* chore: add blst and blstrs packages bumping dependency version needed to resolve ferrilab/funty#3 * chore: remove bls12-381 curve implementation plan is to migrate to `blst` crate * refactor: move common data structures * chore: add rustfmt config * feat: add public facing error type * feat: migrate secret key generation using blst * chore: remove hkdf package * fix: accept review comment Co-authored-by: Tobias Looker <[email protected]> * fix: accept review comment Co-authored-by: Tobias Looker <[email protected]> * fix: accept review comment Co-authored-by: Tobias Looker <[email protected]> * fix: accept review comment Co-authored-by: Tobias Looker <[email protected]> * feat: base SecretKey upon blstrs::Scalar - using blstrs::Scalar gives a bit abstraction over blst_scalar - we can switch or additionally support any `ff` and `group` based impl * feat: migrating public key generation to blst Fixes #16 * chore: cargo fmt * chore: apply suggestions from code review Co-authored-by: Tobias Looker <[email protected]> * chore: fix review comments Co-authored-by: Tobias Looker <[email protected]>
This is still affecting the ecosystem (or to put bluntly: me). Please yank the 1.2.0 version out. Specifically, because your libraries sit at the top of the dependency tree of a lot of libraries, dealing with their inconsistency is very annoying because rust doesn't really have a good mechanism for overriding dependencies of dependencies. |
Yanked. Apologies for the headache and long wait. It's been a ...time. |
this is some npm level shit wow ferrilab/funty#3
this is some npm level shit wow ferrilab/funty#3
This version was yanked from crates.io after causing [breakage][1] in `bitvec 0.19.4`. However, `bitvec 0.22` was still [dependent][2] on it. [1]: ferrilab/funty#3 [2]: ferrilab/funty#7
Create a new crate, add dependence on nom 6.1 version will reproduce compilation errors:
ref: ferrilab/bitvec#105
The text was updated successfully, but these errors were encountered: