Ape init should come with a starter template by default

[miohtama]

Overview

Provide a simple overview of what you wish to see added. Please include:

• Getting started with ape is more difficult than with the other smart contract development frameworks, based on my experience of trying Populus, Truffle, Brownie, Hardhat and Forge
• This is because the default ape init does not by default generate a useable project
• ape init can be configured to use a Github template, but this is not the default behaviour

Specification

ape init should come with a hello world or Counter example, like Forge does.

• User can choose (interactively) between Solidity and Vyper
• User would need to explicitly choose not to use a project template
• Solidity example should include OpenZeppelin contract dependencies by default, as everyone uses them
• There should be an example unit test
• There should be an example README.md with example commands generated
• Github CI can be configured to ensure the default generated project compile and and tests run

[fubuloubu]

So, we have ape-template which is a 2nd party plugin we used to work with cookiecutter, which is a much more advanced templating system using Jinja2. Several of the features you proposed exist in that plugin already

We have an issue about merging that into ape as a 1st class plugin, and merging with the ape init featureset so that it works the way you expect

We could then have a "demo project" like you suggest, or just by default ask the user if they want to use one of the pre-configured templates we have under this org, and then as a last option just a blank project using what ape init currently has, which is only folders and an ape-config.yaml.

This would be alongside the normal use of ape template which allows using any repo (cookiecutter-enabled or not) as a template to copy from, which is very powerful on it's own for getting started with things like https://github.com/yearn/tokenized-strategy-ape-mix

[antazoey]

related: https://github.com/ApeWorX/ape/issues/1556

[rafael-abuawad]

I think it's better to have a completely empty project because it removes the step of removing everything that you are not going to use. The only time that a starter project may be useful is:

1. You are a complete beginner and don't know what you are doing.
2. You want to start working based on existing work.

In both cases a plugin is available. A solution could be to add a flag like --template or --scaffold to add starter files,

[fubuloubu]

I think it's better to have a completely empty project because it removes the step of removing everything that you are not going to use. The only time that a starter project may be useful is:

1. You are a complete beginner and don't know what you are doing.
2. You want to start working based on existing work.

In both cases a plugin is available. A solution could be to add a flag like --template or --scaffold to add starter files,

yes, this is what I am thinking too

The basic flow would be something like this:

$ ape init  # with no flags
What type of project would you like to start:
1. Template project
2. Empty project
3. Simple example

Choose one or hit enter [3]:

And then if you hit enter you get the basic template project as a simple example

If you hit 1, it'll walk through the current ape template flow after you give it a string for the template

and you can also do ape init --template <template uri> to get the template, or ape init --example to get the basic example, or ape init --empty to get the empty project

[miohtama]

I think it's better to have a completely empty project because it removes the step of removing everything that you are not going to use. The only time that a starter project may be useful is:

After my few days of experimenting with Ape I see that it is still very early for external developers to try this tool.

• Basic user stories (install, add dependencies, add compiler, compile dependencies, compile your own project, deploy, verify) cannot be completed because they are broken or documentation does not cover basics, or the documentation is cluttered over different pages and tutorials and YouTube videos in hard to digest furball
• Completing the full flow of the basic user stories is a requirement for this project to succeed. Developers will be turned off and just go to use other tools when they hit the first roadblock, which seems to be obvious for a third party developer, but a tool supports it very poorly.
• Creating a completely empty project may work for an internal Ape user, but it surely does not work for a third-party developer
• For Ape to be successful and adopted, it needs to work for third-party developers easily, so that they do not need to go to documentation and Discord at all
• A developer must get a success experience when they try the tool for the first time "wow this is so much better than X", because there are many Xs and Ys out there for Ethereum developers
• Any design choice that does not contribute towards the above goal is a design choice that will make Ape less likely to successful, whether it is done for the reason of being afraid of being opinionated, personal preference or some other

I see that one (only?) way to address this is that

• There needs to be an example project
• Documentation needs to refer to this stable example project, because that's what the users see on their hard drive folder
• The example project needs to be covered by basic integration or manual testing so that it does not get broken

Saying "just use a plugin" is a turn off for third-party developers, and when they hear those words they will just walk away. If someone wants an empty project they can always do it by hand with mkdir and then put in the files they want to customise themselves, as they know what they are doing. But this is the exception, not the rule.

For the benchmark ape should aim to have feature and documentation parity with Foundry.

[fubuloubu]

I think the Ape experience may end up looking a little different than Foundry, because we don't bundle compilers by default. Compilers can be installed, but the extra step might be a turn off.

What's the best user story (or stories) we can optimize for? I think the average beginner dev has a Python background and wants to do something simple like a Uniswap trade from Python. We can optimize our examples for this (Ape does come bundled with ways of using dependency projects), and show off a script that implements a trade (on Sepolia testnet?) after walking through how to create an account and get testnet tokens

We have tried Vyper devs as a user story to optimize for in the past, I think that is another user story we can optimize for, but the more I think about it the more I think Python chain ops is a user story worth optimizing for as well