pyproject.toml based ape configuration [APE-1238]

antazoey commented 1 year ago

Elevator pitch:

This pitch to document the pros and cons of switching from ape-config.yaml to pyproject.toml, as part of 1.0 release of the framework.

Many python tools are all using the single pyproject.toml file now. If your smart contract project uses ape test and ape run extensively, pyproject.toml is really nice because you can configure all your python tools together.

However, if your project only uses Ape a little bit and it uses Foundry (rust) or Hardhat (javascript) a lot more extensively, forcing the user to use the pyproject.toml is a worse experience than having a simple ape-config.yaml to configure the tool.

So there are definitely pros and cons to both; you really need to wear the different hats and think about what you would want to do.

Por que no los dos

Well, we have the ProjectAPI hook right now which allows a hook for reading configs... But it may be a lot more clearer even after the 1.0 launch where we revamp the plugin system a bit (and the project system honestly). But in any case, we can create a plugin of some kind that uses pyproject.toml and still keep the ape-config.yaml as the "normal" way to configure. Many tools do this still!

Value:

devys

Dependencies:

knowing how pyproject.toml works i guess

Design approach:

mirror config in toml uses known rules for copying them in but still to toml

Task list:

Weigh pros and cons
Decide if need to wait until post plugin revamp
Support
Document

Estimated completion date:

1.0

Design review:

Do not signoff unless:

1. agreed the tasks and design approach will achieve acceptance, and
1. the work can be completed by one person within the SLA. Design reviewers should consider simpler approaches to achieve goals.

(Please leave a comment to sign off)

antazoey commented 1 year ago

I kind of wanted to create this issue because I noticed we did not have it, I want community feedback, we are often discussing it, and I found this conversation in mdformat really interesting: https://github.com/executablebooks/mdformat/issues/356

It is not exactly the same issue as ours but ultimately the same decision

Aviksaikat commented 1 year ago

I think one way we can do it is that based on the pyprojecet.toml we can automatically generate & populate the ape-config.yml. Yeah, we will have to do a lot of hardcoding or maybe we can dynamically populate them based on the entries. I believe keeping both is the go to way for now. I use poetry & I do not like copying this to the ape-config for every project.

From this

[tool.poetry.dependencies]
python = ">=3.10,<3.11"
eth-ape = "^0.6.15"
ape-alchemy = "^0.6.2"
ape-ganache = "^0.6.8"
ape-solidity= "^0.6.7"
ape-foundry = "^0.6.14"

To this

plugins:
- name: solidity
- name: ganache
- name: alchemy
- name: foundry

Don't hate me if I misunderstood the issue or something :sweat_smile:

Aviksaikat commented 1 year ago

If this is the way we want to proceed then I can take a look at implementing this feature

fubuloubu commented 1 year ago

If this is the way we want to proceed then I can take a look at implementing this feature

I think this would require further research, so if you wanted to research it for us that would really help us in evaluating the solution and any gotchas it might have

Aviksaikat commented 1 year ago

As far as I know pyproject.toml is used mainly to manage project dependencies & stuff. So for now what if we just use it to populate the project name & plugins parts for the ape-config? And eventually, add more options as we move forward.

As far as my daily use case only project name & plugins are the only part that overlaps. In this way, we can keep the provision open for future improvements + upgrades & see how these changes are working out for now by making these small changes.

fubuloubu commented 1 year ago

As far as I know pyproject.toml is used mainly to manage project dependencies & stuff. So for now what if we just use it to populate the project name & plugins parts for the ape-config? And eventually, add more options as we move forward.

As far as my daily use case only project name & plugins are the only part that overlaps. In this way, we can keep the provision open for future improvements + upgrades & see how these changes are working out for now by making these small changes.

I think we should make ape work like a plugin to poetry eventually. For now, what we can do is add the ability to read config from those sections by prepending the tool's name to it e.g. [tool.ape.*] where you can add any first-level config to the toml file e.g. tool.ape.plugins

Aviksaikat commented 1 year ago

Yes, so we can make ape look for the pyproject.toml when we do ape init so that the ape-config.yaml get generated with all the initial info like project name & plugins we want to use.

Aviksaikat commented 1 year ago

I'm making a function to generate the ape-config.yml file. I'm putting this function inside /src/ape_init/_cli.py. I hope it's fine

fubuloubu commented 3 months ago

Good example of how it might look like:

[tool.ape]
contracts_folder = "contracts"

[[tool.ape.dependencies]]
name = "openzeppelin"
github = "OpenZeppelin/openzeppelin-contracts"
version = "x.x.x"

[[tool.ape.plugins]]
name = "hardhat"

[[tool.ape.plugins]]
name = "solidity"
version = "0.8.1"

antazoey commented 2 months ago

something I just realized we will have to consider: global / root pyproject.toml files are a thing. So now there will be 2 places for root Ape config, unless we deprecate the ~/.ape one

ApeWorX / ape