Skip to content
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

Add fixed-hash and uint crates to parity-common #12

Merged
merged 89 commits into from
Aug 3, 2018
Merged

Conversation

dvdplm
Copy link
Contributor

@dvdplm dvdplm commented Jul 13, 2018

Both susbtrate and ethereum-types use fixed-hash to build their hash types so it's getting moved here. uint is also moved as it is used in a few places in substrate.

The new code here is from d2e4ec5 and fixes a compiler warning and adds a test.

One thing I am not happy with is that uints tests have to be run with cargo test --features=std,impl_quickcheck_arbitrary. Advice on how to fix that so cargo test works is much appreciated.

debris and others added 30 commits October 24, 2017 16:09
* add rustc_version to build deps of ether types (needed by build script)

* ethereum-types: add build script that sets cargo:rustc-cfg=asm_available on nightly

* ethereum-types: #![cfg_attr(asm_available, feature(asm))]

* tests: add the whole feature asm build script to make it pass on nightly CI

* add #![cfg_attr(asm_available, feature(asm))] directly where needed

so users don't have to add it

* remove tests/build.rs since it should not be needed anymore

* move inner cfg_attr attributes to the right allowed position

* remove check for asm_available in contexts that already have check for that
* feature(asm) is only allowed in crate

* add tests/build.rs again - haven't found a way around it
* feature(asm) is only allowed in crate

* add tests/build.rs again - haven't found a way around it
@tomusdrw
Copy link
Contributor

I don't really get the reasoning for the move. The crate only exposes a macro to generate your own types, so it's only referenced by at most one crate.

paritytech/primitives already contains all the crates required to build uint/hashes, and doesn't depend on other git repos. Now ethereum_types for instance have to pull in parity-common repo?

None of the crates in this repo will ever dependend on fixed-hash, so I don't get what do we gain by having it here instead of in primitives.

IMHO we etiher keep parity-common and primitives separate or we dissolve primitives and move ALL crates here. Moving only fixed-hash doesn't make much sense to me.

@dvdplm dvdplm changed the title Add fixed-hash to parity-common Add fixed-hash and uint crates to parity-common Jul 13, 2018

#[cfg(feature="std")]
#[doc(hidden)]
pub extern crate core;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are all these crates pub?

implementations for even more speed, hidden behind the `x64_arithmetic`
feature flag.

Run tests with `cargo test --features=std,impl_quickcheck_arbitrary`.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How can I improve this? :/

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried that and no, it's not really doing what I'd like. With:

[[test]]
name = "uint_tests"
required-features = ["std,impl_quickcheck_arbitrary"]

…I can run cargo test and all tests are skipped which is better than spewing errors, but now cargo test --features=std,impl_quickcheck_arbitrary also skips all tests.

What I'm looking for is a way to tell cargo "when running cargo test use this set of features: … … ".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

UPDATE: seems to be a known limitation

@dvdplm dvdplm removed the A1-onice label Jul 13, 2018
@twittner
Copy link
Contributor

Like @tomusdrw I am somewhat puzzled by this. Would the motivation behind parity-common not make it logical to put all primitive crates in here? But what prevents parity-common from becoming a black hole of crates? What about other repositories, e.g. paritytech/exit-future, paritytech/bigint, etc.? I guess the question I have is: When should a crate be a member of parity-common instead of being in a separate repository?

@dvdplm
Copy link
Contributor Author

dvdplm commented Jul 30, 2018

Would the motivation behind parity-common not make it logical to put all primitive crates in here?

Some of the code in primitives is ethereum-specific and should thus not be in parity-common.

what prevents parity-common from becoming a black hole of crates?

This is a great question and a concern I have too. The answer is, I guess, "we're disciplined about what we move". And "one could argue that parity-ethereum is already a black hole of crates and at least this new black hole is built with the strict requirement of code being used in more than one project".

The background conversation here is the tension between two valid but conflicting ergonomical concerns:

  1. splitting out code into own repos is great for consumers (easy to version, publish, and pull into other projects)
  2. maintaining and updating a crate is much more comfortable when changes can be made in a single repo and with a single PR

The parity-common effort tries to find a middle ground between the two. And as mentioned, the criterium used is pretty pragmatic: "crates used in more than one Parity project that are not not already split out into their own repos".
As mentioned above I am also worried that we'll end up with big pile of unrelated crates and be back at square one, but I am also convicned that leaving things as they are is not a good option: we really really don't want to maintain forks and/or risk loosing track of what code is used where.

fn uint256_mul32_old() {
assert_eq!(U256::from(0u64).mul_u32(2), U256::from(0u64));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Accidentally duplicated line

@dvdplm
Copy link
Contributor Author

dvdplm commented Aug 1, 2018

@tomusdrw @twittner @debris do you still have concerns about this?

@dvdplm dvdplm merged commit ae80aff into master Aug 3, 2018
@debris debris deleted the add-fixed-hash branch August 6, 2018 08:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.