milksad
/
rust-bitcoin-unsafe-fast
14
0
Fork 0
Code Issues Pull Requests Activity
rust-bitcoin-unsafe-fast/hashes/extended_tests/schemars/Cargo.toml

27 lines
528 B
TOML
Raw Normal View History

Import bitcoin_hashes crate into hashes We would like to bring the `bitcoin_hashes` crate into the `rust-bitcoin` repository. Import `bitcoin_hashes` into `rust-bitocin/hashes`, doing so looses all the commit history from the original crate but if we archive the original repository then the history will be preserved. We maintain the same version number obviously and in the changelog we note the change of repository. Commit hash that was tip of `bitcoin_hashes` at time of import: commit 54c16249e06cc6b7870c7fc07d90f489d82647c7 Includes making `embedded` and `fuzzing` per-crate i.e., move them into `bitcoin` as hashes includes these also. NOTE: Does _not_ enable fuzzing for `hashes` in CI. Notes on CI: Attempts to merge in the github actions from the hashes crate however reduces coverage by not running hashes tests for beta toolchain. Some additional work could be done to improve the CI to increase efficiency without reducing coverage. Leaving for another day.
2022-09-16 01:52:57 +00:00
[package]
name = "schemars"
version = "0.1.0"
authors = ["Jeremy Rubin <j@rubin.io>"]
edition = "2018"
# Prevent this from interfering with workspaces
[workspace]
members = ["."]
[dependencies.bitcoin_hashes]
path = "../.."
features = ['schemars', 'serde']
[dependencies]
Fix pinning (schemars and MSRV) Done as is single patch to make sure all the docs and CI are in sync and correct. We currently pin the `schemars` dependency using `<=0.8.3` as well as a the `dyn-clone` transient dependency in the manifest (`hashes` and the extended test crate). This is incorrect because it makes usage of the crate klunky (or possibly impossible) if downstream users wish to use a later version of `schemars`. Observe also that we do not have to pin `schemars`, we do however have to pin the `serde` crate if either `serde` or `schemars` features are enabled. Do so in CI and document in the readme file within hashes. Currently we have a pin remaining from the old MSRV (`syn` due to use of `matches!`). Fix pinning by: - Remove pin in manifest for `schemars` - Fix pinning for MSRV in CI and docs (this includes documenting pinning requirements for `schemars` feature because it is related to the other pin of `serde`) in both `hashes` readme and main repo readme.
2023-03-06 22:39:20 +00:00
jsonschema-valid = "0.4.0"
Import bitcoin_hashes crate into hashes We would like to bring the `bitcoin_hashes` crate into the `rust-bitcoin` repository. Import `bitcoin_hashes` into `rust-bitocin/hashes`, doing so looses all the commit history from the original crate but if we archive the original repository then the history will be preserved. We maintain the same version number obviously and in the changelog we note the change of repository. Commit hash that was tip of `bitcoin_hashes` at time of import: commit 54c16249e06cc6b7870c7fc07d90f489d82647c7 Includes making `embedded` and `fuzzing` per-crate i.e., move them into `bitcoin` as hashes includes these also. NOTE: Does _not_ enable fuzzing for `hashes` in CI. Notes on CI: Attempts to merge in the github actions from the hashes crate however reduces coverage by not running hashes tests for beta toolchain. Some additional work could be done to improve the CI to increase efficiency without reducing coverage. Leaving for another day.
2022-09-16 01:52:57 +00:00
serde = { version = "1.0", default-features = false}
Fix pinning (schemars and MSRV) Done as is single patch to make sure all the docs and CI are in sync and correct. We currently pin the `schemars` dependency using `<=0.8.3` as well as a the `dyn-clone` transient dependency in the manifest (`hashes` and the extended test crate). This is incorrect because it makes usage of the crate klunky (or possibly impossible) if downstream users wish to use a later version of `schemars`. Observe also that we do not have to pin `schemars`, we do however have to pin the `serde` crate if either `serde` or `schemars` features are enabled. Do so in CI and document in the readme file within hashes. Currently we have a pin remaining from the old MSRV (`syn` due to use of `matches!`). Fix pinning by: - Remove pin in manifest for `schemars` - Fix pinning for MSRV in CI and docs (this includes documenting pinning requirements for `schemars` feature because it is related to the other pin of `serde`) in both `hashes` readme and main repo readme.
2023-03-06 22:39:20 +00:00
schemars = "0.8.3"
Import bitcoin_hashes crate into hashes We would like to bring the `bitcoin_hashes` crate into the `rust-bitcoin` repository. Import `bitcoin_hashes` into `rust-bitocin/hashes`, doing so looses all the commit history from the original crate but if we archive the original repository then the history will be preserved. We maintain the same version number obviously and in the changelog we note the change of repository. Commit hash that was tip of `bitcoin_hashes` at time of import: commit 54c16249e06cc6b7870c7fc07d90f489d82647c7 Includes making `embedded` and `fuzzing` per-crate i.e., move them into `bitcoin` as hashes includes these also. NOTE: Does _not_ enable fuzzing for `hashes` in CI. Notes on CI: Attempts to merge in the github actions from the hashes crate however reduces coverage by not running hashes tests for beta toolchain. Some additional work could be done to improve the CI to increase efficiency without reducing coverage. Leaving for another day.
2022-09-16 01:52:57 +00:00
serde_test = "1.0"
serde_json = "1.0"
Add patch section to test crates In order to keep the embedded and schemacs test crates building when we update their local transient dependencies we need to use a `patch` section. - For `bitcoin/embedded` add `patch` section for `internals`, `hashes` already has an entry. - For `hashes/embedded` add `patch` section for `internals`. - For `hashes/extendend_tests/schemars` add `patch` section for `internals`. FTR for direct local dependencies we use a `path` field when specifying the dependency.
2023-06-27 23:25:21 +00:00
[patch.crates-io.bitcoin-internals]
path = "../../../internals"
Add a `bitcoin_io` crate In order to support standard (de)serialization of structs, the `rust-bitcoin` ecosystem uses the standard `std::io::{Read,Write}` traits. This works great for environments with `std`, however sadly the `std::io` module has not yet been added to the `core` crate. Thus, in `no-std`, the `rust-bitcoin` ecosystem has historically used the `core2` crate to provide copies of the `std::io` module without any major dependencies. Sadly, its one dependency, `memchr`, recently broke our MSRV. Worse, because we didn't want to take on any excess dependencies for `std` builds, `rust-bitcoin` has had to have mutually-exclusive `std` and `no-std` builds. This breaks general assumptions about how features work in Rust, causing substantial pain for applications far downstream of `rust-bitcoin` crates. Here, we add a new `bitcoin_io` crate, making it an unconditional dependency and using its `io` module in the in-repository crates in place of `std::io` and `core2::io`. As it is not substantial additional code, the `hashes` io implementations are no longer feature-gated. This doesn't actually accomplish anything on its own, only adding the new crate which still depends on `core2`.
2023-10-04 05:51:26 +00:00
[patch.crates-io.bitcoin-io]
path = "../../../io"