Big picture view

I’ve spent some more time thinking how to organize cairo projects and what I’d like to see. I think we should leverage the python ecosystem as much as possible:

• nile init could use cookiecutter to create the project
• pypi to distribute cairo packages
• users should be able to configure nile (for example the contracts directory) from their setup.cfg file like other python tools

I think cairo projects should use the same folder structure as python projects, this has the added benefit that library developers can distribute the cairo files together with an sdk to interact with it (like @uniswap/core and @uniswap/sdk).

.
├── src
│  └── cairoswap
│     ├── __init__.py
│     ├── cairo
│     │  ├── __init__.py
│     │  ├── pool.cairo
│     │  └── router.cairo
│     ├── pool.py
│     └── router.py
├── tests
│  ├── pool.test.cairo
│  ├── test_pool.py
│  └── test_router.py
├── pyproject.toml
├── setup.cfg
└── tox.in

Developers can then create a tox task than runs python tests with pytest and cairo tests with nile test.

If users don’t need/want to setup a full blown project they can revert to a minimal setup and use nile to build and test.

.
└── src
   ├── pool.cairo
   └── pool.test.cairo

[martriay]

On point questions, Eric. The way I see Nile today is as a collective experiment on how Cairo development looks or could look like, and it is materialized in a poorly defined array of tooling, functionality and libraries that may arise on the way.

Cairo is a rapidly evolving language and environment, its API changes week over week. Some Nile features may arise and some we might need to sunset. I’ve been adding and removing development utils here and in the contracts repo I’m working on, and I expect it continues to be the case for a while.

My intention is for Nile to serve as a vehicle for the Cairo community to share insights and best practices to accelerate the ecosystem and its development experience. That’s why questions such as how projects should be structured, packages distributed also belong in here. Today this dev experience improvement is achieved through a small set of utils aiding bootstrapping and task automation, but it can be anything 🌈 . For example, @fracek is experimenting with Cairo native testing.

[fracek]

After discussing here and on Discord I changed my mind and I agree with more points that you brought up.

Development environment

[…]

So my proposal moving forward is: let’s stick with python but with an open mind of moving away as soon as/if the compiler gets distributed differently.

I completely agree with this. I think now setting up a Python environment is the best way to get a StarkNet project running, but in the future who knows?

On the other hand, dapp tools show that people are willing to setup extra package managers (nix in their case) if the tool is worth it. I don’t necessarily believe that’s good, but it’s something to consider 😃

Directory structure (for #1)

[…] I still believe minimizing dependencies is very important when designing dev environments.

I tend to agree with this, on the other hand minimizing the work a user needs to get the project running is also important. See how create-react-app became a standard even though they pull a bazillion dependencies on project setup.

After discussing with you I now agree that init should return a more minimal structure and developers can provide their more opinionated templates through cookiecutter or other tools.

[…]

For 2, I might be wrong but my impression is that usually client interfaces belongs to a different repo/project and are distributed as such. Usually you either extend a smart contract codebase or try to interact with an existing one, if you happen to do both it’s ok to install two different dependencies.

Good point, Python also makes it terrible to have multiple packages in the same repo. Now I can see only testing helpers shipped with the contracts package.

[…]

Therefore, I’d focus on 1 only, and with something simple as:

Looks good, I think we can replace pyproject.toml, setup.cfg, and tox.ini with a Makefile that calls nile. That reduces the project dependencies to two “globally” (per virtual environment) installed tools (because of how Python dependencies work, even if the dependencies where specified in setup.cfg they would be global for the virtual environment).

Edit: I think using Makefiles also means we are not pushing a package manager to users, which can for example use git submodules for dependencies.