chore: rename to Alloy (#69)

* chore: add `workspace.package.exclude`

* chore: rename to alloy-rs

* docs: update README.md

* docs: update package descriptions

* chore: rename to Alloy

CONTRIBUTING.md

@@ -1,9 +1,9 @@
-# Contributing to ethers-rs
+# Contributing to Alloy
 
 :balloon: Thanks for your help improving the project! We are so happy to have
 you!
 
-There are opportunities to contribute to ethers-rs at any level. It doesn't
+There are opportunities to contribute to Alloy at any level. It doesn't
 matter if you are just getting started with Rust or are the most weathered
 expert, we can use your help.
 
@@ -19,7 +19,7 @@ please join us!
 
 ## Conduct
 
-The ethers-rs project adheres to the [Rust Code of Conduct][coc]. This describes
+The Alloy project adheres to the [Rust Code of Conduct][coc]. This describes
 the _minimum_ behavior expected from all contributors. Instances of violations
 of the Code of Conduct can be reported by contacting the project team at
 [james@prestwich](mailto:james@prestwi.ch).
@@ -31,7 +31,7 @@ of the Code of Conduct can be reported by contacting the project team at
 For any issue, there are fundamentally three ways an individual can contribute:
 
 1. By opening the issue for discussion: For instance, if you believe that you
-   have uncovered a bug in ethers-rs, creating a new issue in the ethers-rs
+   have uncovered a bug in Alloy, creating a new issue in the Alloy
    issue tracker is the way to report it.
 
 2. By helping to triage the issue: This can be done by providing
@@ -42,7 +42,7 @@ For any issue, there are fundamentally three ways an individual can contribute:
 3. By helping to resolve the issue: Typically this is done either in the form of
    demonstrating that the issue reported is not a problem after all, or more
    often, by opening a Pull Request that changes some bit of something in
-   ethers-rs in a concrete and reviewable manner.
+   Alloy in a concrete and reviewable manner.
 
 **Anybody can participate in any stage of contribution**. We urge you to
 participate in the discussion around bugs and participate in reviewing PRs.
@@ -57,7 +57,7 @@ PR that helps others avoid the problems that you encountered.
 
 ### Submitting a Bug Report
 
-When opening a new issue in the ethers-rs issue tracker, users will be presented
+When opening a new issue in the Alloy issue tracker, users will be presented
 with a [basic template][template] that should be filled in. If you believe that
 you have uncovered a bug, please fill out this form, following the template to
 the best of your ability. Do not worry if you cannot answer every detail, just
@@ -69,7 +69,7 @@ test case we can use to recreate the problem on our own. If we cannot recreate
 the issue, it becomes impossible for us to fix.
 
 In order to rule out the possibility of bugs introduced by userland code, test
-cases should be limited, as much as possible, to using only ethers-rs APIs.
+cases should be limited, as much as possible, to using only Alloy APIs.
 
 See [How to create a Minimal, Complete, and Verifiable example][mcve].
 
@@ -101,12 +101,12 @@ In the majority of cases, issues are resolved by opening a Pull Request. The
 process for opening and reviewing a Pull Request is similar to that of opening
 and triaging issues, but carries with it a necessary review and approval
 workflow that ensures that the proposed changes meet the minimal quality and
-functional guidelines of the ethers-rs project.
+functional guidelines of the Alloy project.
 
 ## Pull Requests
 
 Pull Requests are the way concrete changes are made to the code, documentation,
-and dependencies in the ethers-rs repository.
+and dependencies in the Alloy repository.
 
 Even tiny pull requests (e.g., one character pull request fixing a typo in API
 documentation) are greatly appreciated. Before making a large change, it is
@@ -118,7 +118,7 @@ merged.
 
 This section lists some commonly needed commands.
 
-```
+```sh
 cargo check --all-features
 cargo +nightly fmt --all
 cargo build --all-features
@@ -129,9 +129,9 @@ cargo +nightly clippy --all-features
 ### Tests
 
 If the change being proposed alters code (as opposed to only documentation for
-example), it is either adding new functionality to ethers-rs or it is fixing
+example), it is either adding new functionality to Alloy or it is fixing
 existing, broken functionality. In both of these cases, the pull request should
-include one or more tests to ensure that ethers-rs does not regress in the
+include one or more tests to ensure that Alloy does not regress in the
 future.
 
 #### Unit Tests
@@ -221,9 +221,9 @@ however, will stay intact on the Pull Request page.
 
 ## Reviewing Pull Requests
 
-**Any ethers-rs community member is welcome to review any pull request**.
+**Any Alloy community member is welcome to review any pull request**.
 
-All ethers-rs contributors who choose to review and provide feedback on Pull
+All Alloy contributors who choose to review and provide feedback on Pull
 Requests have a responsibility to both the project and the individual making the
 contribution. Reviews and feedback must be helpful, insightful, and geared
 towards improving the contribution as opposed to simply blocking it. If there
@@ -250,8 +250,8 @@ perfect grammar, or exact style matches. Do not succumb to that temptation.
 
 Focus first on the most significant aspects of the change:
 
-1. Does this change make sense for ethers-rs?
-2. Does this change make ethers-rs better, even if only incrementally?
+1. Does this change make sense for Alloy?
+2. Does this change make Alloy better, even if only incrementally?
 3. Are there clear bugs or larger scale issues that need attending to?
 4. Is the commit message readable and correct? If it contains a breaking change
    is it clear enough?
@@ -268,7 +268,7 @@ change over time. The first impression you give to a new contributor never does.
 
 Nits (requests for small changes that are not essential) are fine, but try to
 avoid stalling the Pull Request. Most nits can typically be fixed by the
-ethers-rs Collaborator landing the Pull Request but they can also be an
+Alloy Collaborator landing the Pull Request but they can also be an
 opportunity for the contributor to learn a bit more about the project.
 
 It is always good to clearly indicate nits when you comment: e.g.
@@ -282,8 +282,8 @@ with the appropriate reason to keep the conversation flow concise and relevant.
 
 Be aware that _how_ you communicate requests and reviews in your feedback can
 have a significant impact on the success of the Pull Request. Yes, we may land
-a particular change that makes ethers-rs better, but the individual might just
-not want to have anything to do with ethers-rs ever again. The goal is not just
+a particular change that makes Alloy better, but the individual might just
+not want to have anything to do with Alloy ever again. The goal is not just
 having good code.
 
 ### Abandoned or Stalled Pull Requests

Cargo.toml

@@ -1,27 +1,29 @@
 [workspace]
-resolver = "2"
 members = ["crates/*"]
+resolver = "2"
 
 [workspace.package]
+version = "0.1.0"
 edition = "2021"
-rust-version = "1.65" # Remember to update .clippy.toml and workflows/ci.yml
-authors = []
+rust-version = "1.65"
+authors = ["Alloy Contributors"]
 license = "MIT OR Apache-2.0"
-homepage = "https://github.com/ethers-rs/core"
-repository = "https://github.com/ethers-rs/core"
+homepage = "https://github.com/alloy-rs/core"
+repository = "https://github.com/alloy-rs/core"
+exclude = ["benches/", "tests/"]
 
 [workspace.metadata.docs.rs]
 all-features = true
 rustdoc-args = ["--cfg", "docsrs"]
 
 [workspace.dependencies]
 # workspace crates
-ethers-dyn-abi = { version = "0.1.0", path = "crates/dyn-abi", default-features = false }
-ethers-primitives = { version = "0.1.0", path = "crates/primitives", default-features = false }
-ethers-rlp = { version = "0.1.0", path = "crates/rlp", default-features = false }
-ethers-rlp-derive = { version = "0.1.0", path = "crates/rlp-derive", default-features = false }
-ethers-sol-macro = { version = "0.1.0", path = "crates/sol-macro", default-features = false }
-ethers-sol-types = { version = "0.1.0", path = "crates/sol-types", default-features = false }
+alloy-dyn-abi = { version = "0.1.0", path = "crates/dyn-abi", default-features = false }
+alloy-primitives = { version = "0.1.0", path = "crates/primitives", default-features = false }
+alloy-rlp = { version = "0.1.0", path = "crates/rlp", default-features = false }
+alloy-rlp-derive = { version = "0.1.0", path = "crates/rlp-derive", default-features = false }
+alloy-sol-macro = { version = "0.1.0", path = "crates/sol-macro", default-features = false }
+alloy-sol-types = { version = "0.1.0", path = "crates/sol-types", default-features = false }
 syn-solidity = { version = "0.1.0", path = "crates/syn-solidity", default-features = false }
 
 ruint = { version = "1.8.0", git = "https://github.com/recmo/uint", default-features = false }

README.md

@@ -1,84 +1,75 @@
-<h1 align="center"> ethers-rs core </h1>
+# Alloy
 
-This repository holds the core crates at the root of the the ethers-rs
-ecosystem. These types and libraries will be used by revm, reth, ethers, and
-foundry.
+Core libraries at the root of the Rust Ethereum ecosystem.
 
-## What's in the box?
+[![Build Status][actions-badge]][actions-url]
+[![Telegram chat][telegram-badge]][telegram-url]
 
-This repository contains the following crates:
-
-- **ethers-rlp** - A Rust implementation of the Ethereum RLP encoding.
-- **ethers-rlp-derive** - A derive macro for RLP encoding.
-- **ethers-primitives** - Signed & unsigned integers, and fixed-sized
-  bytearrays.
-- **ethers-sol-types** - Rust representation of Solidity types with ABI and
-  EIP-712 encoding.
-- **ethers-sol-macro** - A macro for generating Rust representations of Solidity
-  types by parsing Solidity snippets.
-- **ethers-dyn-abi** - ABI encoding and decoding of types that are not known at
-  runtime.
-- **ethers-serde-helpers** - Serde helpers for the ethers crates (coming soon).
-
-## Developer Information
-
-No special actions needed. Clone the repo and make sure rust is installed
-
-### Build commands
-
-- `$ cargo clippy`
-- `$ cargo clippy --no-default-features`
-- `$ cargo clippy --all-features`
+[actions-badge]: https://img.shields.io/github/actions/workflow/status/alloy-rs/core/ci.yml?branch=main&style=for-the-badge
+[actions-url]: https://github.com/alloy-rs/core/actions?query=branch%3Amain
+[telegram-badge]: https://img.shields.io/endpoint?color=neon&style=for-the-badge&url=https%3A%2F%2Ftg.sumanjay.workers.dev%2Fethers_rs
+[telegram-url]: https://t.me/ethers_rs
 
-### Testing commands
+## Overview
 
-- `$ cargo test`
-- `$ cargo test --no-default-features`
-- `$ cargo test --all-features`
-
-### MSRV
-
-We do not guarantee a specific MSRV. We like to keep up-to-date and take
-advantage of new features.
-
-### Features
+This repository contains the following crates:
 
-- `ethers-rlp/std` - `std` support for `ethers-rlp` Enabled by default.
-- `ethers-primitives/rlp` - `rlp` support for `ethers-primitives` Enabled by
-  default.
-- `ethers-primitives/serde` - `serde` support for `ethers-primitives` Enabled by
-  default.
-- `ethers-sol-types/eip712-serde` - `serde` support for the `Eip712Domain`
-  struct.
+- [`alloy-primitives`] - Primitive integer and byte types
+- [`alloy-rlp`] - Implementation of [Ethereum RLP serialization][rlp]
+- [`alloy-rlp-derive`] - Derive macros for `alloy-rlp`
+- [`alloy-dyn-abi`] - Run-time ABI and [EIP-712] implementations
+- [`alloy-sol-types`] - Compile-time ABI and [EIP-712] implementations
+- [`alloy-sol-macro`] - The `sol!` procedural macro
+- [`syn-solidity`] - [`syn`]-powered Solidity parser, used by `alloy-sol-macro`
+
+[`alloy-primitives`]: ./crates/alloy-primitives
+[`alloy-rlp`]: ./crates/alloy-rlp
+[`alloy-rlp-derive`]: ./crates/alloy-rlp-derive
+[`alloy-sol-types`]: ./crates/alloy-sol-types
+[`alloy-sol-macro`]: ./crates/alloy-sol-macro
+[`alloy-dyn-abi`]: ./crates/alloy-dyn-abi
+[`syn-solidity`]: ./crates/syn-solidity
+
+[rlp]: https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp
+[EIP-712]: https://eips.ethereum.org/EIPS/eip-712
+[`syn`]: https://github.com/dtolnay/syn
+
+## Supported Rust Versions
+
+<!--
+When updating this, also update:
+- .clippy.toml
+- Cargo.toml
+- .github/workflows/ci.yml
+-->
+
+Alloy will keep a rolling MSRV (minimum supported rust version) policy of **at
+least** 6 months. When increasing the MSRV, the new Rust version must have been
+released at least six months ago. The current MSRV is 1.65.0.
+
+Note that the MSRV is not increased automatically, and only as part of a minor
+release.
 
 ## Contributing
 
 Thanks for your help improving the project! We are so happy to have you! We have
 [a contributing guide](./CONTRIBUTING.md) to help you get involved in the
-ethers-rs project.
-
-If you open a Pull Request, do not forget to add your changes in the
-[CHANGELOG](./CHANGELOG.md).
+Alloy project.
 
 Pull requests will not be merged unless CI passes, so please ensure that your
-contribution follows the linting rules and passes clippy. :)
+contribution follows the linting rules and passes clippy.
 
-## Note on WASM and FFI bindings
+## Note on WASM
 
-You should be able to build a wasm app that uses ethers-rs. If ethers fails to
-compile in WASM, please
-[open an issue]. There is
-currently no plan to provide an official JS/TS-accessible library interface. We
-believe [viem](https://viem.sh) or [ethers.js](https://docs.ethers.io/v6/)
-serves that need very well.
+We provide full support for all the `wasm*-*` targets. If any crate does not
+build on a WASM target, please [open an issue].
 
-Similarly, you should be able to build FFI bindings to ethers-rs. If ethers
-fails to compile in c lib formats, please
-[open an issue].
-There is currently no plan to provide official FFI bindings, and as ethers-rs is
-not yet stable 1.0.0, its interface may change significantly between versions.
+There is currently no plan to provide an official JS/TS-accessible library
+interface, as we believe [viem] or [ethers.js] serve that need very well.
 
-[open an issue]: https://github.com/ethers-rs/core/issues/new
+[viem]: https://viem.sh
+[ethers.js]: https://docs.ethers.io/v6/
+[open an issue]: https://github.com/alloy-rs/core/issues/new
 
 ## Note on `no_std`
 
@@ -89,14 +80,10 @@ contribute upstream PRs to achieve it in ruint.
 
 ## Credits
 
-These librarires would not have been possible without the great work done in:
+None of these crates would have been possible without the great work done in:
 
 - [`ethers.js`](https://github.com/ethers-io/ethers.js/)
 - [`rust-web3`](https://github.com/tomusdrw/rust-web3/)
 - [`ethcontract-rs`](https://github.com/gnosis/ethcontract-rs/)
 - [`guac_rs`](https://github.com/althea-net/guac_rs/)
 - [`ruint`](https://github.com/recmo/uint)
-
-A lot of the code was inspired and adapted from them, to a unified and
-opinionated interface, built with async/await and std futures from the ground
-up.

crates/dyn-abi/Cargo.toml

@@ -1,30 +1,30 @@
 [package]
-name = "ethers-dyn-abi"
-version = "0.1.0"
-description = "Ethereum ABI encoding and decoding, with runtime typing"
-readme = "README.md"
+name = "alloy-dyn-abi"
+description = "Run-time ABI and EIP-712 implementations"
 keywords = ["ethereum", "abi", "encoding", "EVM", "solidity"]
-categories = ["encoding", "cryptography::cryptocurrencies"]
+categories = ["no-std", "encoding", "cryptography::cryptocurrencies"]
+homepage = "https://github.com/alloy-rs/core/tree/main/crates/dyn-abi"
 
+version.workspace = true
 edition.workspace = true
 rust-version.workspace = true
 authors.workspace = true
 license.workspace = true
-homepage.workspace = true
 repository.workspace = true
+exclude.workspace = true
 
 [package.metadata.docs.rs]
 all-features = true
 rustdoc-args = ["--cfg", "docsrs"]
 
 [dependencies]
-ethers-sol-types = { workspace = true, features = ["eip712-serde"] }
-ethers-primitives.workspace = true
+alloy-sol-types = { workspace = true, features = ["eip712-serde"] }
+alloy-primitives.workspace = true
 
 hex.workspace = true
 serde.workspace = true
 serde_json = { workspace = true, features = ["alloc"] }
 
 [features]
 default = ["std"]
-std = ["ethers-sol-types/std", "ethers-primitives/std", "hex/std", "serde/std", "serde_json/std"]
+std = ["alloy-sol-types/std", "alloy-primitives/std", "hex/std", "serde/std", "serde_json/std"]