add hyperdrive types

[dpaiton]

This PR adds the hyperdrive_types package to lib. This package is comprised of a shell script that recursively parses an abi folder for ABI JSON files, and calls pypechain to generate the corresponding python files. Due to problems described in the discussion below, we opted to also commit the programmatically generated python files to this repo.

Original description of the problem is in this comment below.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
elf-simulations	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 25, 2023 8:10pm

[slundqui]

I think there's a way to run whatever python code you need when you do pip install. Right now, we're using pyproject.toml, which handles that for you, but I think a replacement using setup.py allows you to run arbitrary python code during a pip install. Hence, you can imagine doing pip install pypechain (or having it in requirements.txt) run the codegen stuff. Unfortuantly, there's still the issue of pointing it to the abis

[dpaiton]

I think there's a way to run whatever python code you need when you do pip install. Right now, we're using pyproject.toml, which handles that for you, but I think a replacement using setup.py allows you to run arbitrary python code during a pip install. Hence, you can imagine doing pip install pypechain (or having it in requirements.txt) run the codegen stuff. Unfortuantly, there's still the issue of pointing it to the abis

This is a good option. We should consider 1) that will require modifying our install process everywhere else to be consistent. 2) this is the older method, and the PEPs linked in the PR explain why it's generally better to move to the new pyproject.toml system. 3) it's not clear that this is safer or more transparent or better in any way than a makefile or install.sh file

Pointing it to the ABIs should be fine since we're standardizing where they live (<project_root>/packages/hyperdrive/src/abis).

edit: I guess we could have pypechain use setup.py and the rest of the monorepo use pyproject.toml? i.e. ignore the consistency issue in 1) above

[dpaiton]

@sentilesdal has suggested that we commit the generated code and leave it as a pyproject.toml package. This avoids most of the issues. We now have to be diligent about maintaining the correct version of the generated code & hyperdrive ABIs, which adds a step to the release process. This still seems like a better solution than what I had before, though.

[slundqui]

I like this. You probably could write a test that regenerates the code and ensures the committed versions are correct.