Hello team. I am trying to setup a private key alias as described in the README. but I get an error.

I am on a working installation of Nile on macOS (I followed the macOS specific installations) and I am able to compile and deploy. I created the venv, installed cairo-nile with pip, inited the project. I also create a .env file in the root directory with the YOLO=123 key.

> nile setup YOLO    

Traceback (most recent call last):
  File "/opt/homebrew/bin/nile", line 8, in <module>
    sys.exit(cli())
  File "/opt/homebrew/lib/python3.9/site-packages/click/core.py", line 1128, in __call__
    return self.main(*args, **kwargs)
  File "/opt/homebrew/lib/python3.9/site-packages/click/core.py", line 1053, in main
    rv = self.invoke(ctx)
  File "/opt/homebrew/lib/python3.9/site-packages/click/core.py", line 1659, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/opt/homebrew/lib/python3.9/site-packages/click/core.py", line 1395, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/opt/homebrew/lib/python3.9/site-packages/click/core.py", line 754, in invoke
    return __callback(*args, **kwargs)
  File "/opt/homebrew/lib/python3.9/site-packages/nile/cli.py", line 84, in setup
    Account(signer, network)
  File "/opt/homebrew/lib/python3.9/site-packages/nile/core/account.py", line 20, in __init__
    self.signer = Signer(int(os.environ[signer]))
  File "/opt/homebrew/Cellar/[email protected]/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/os.py", line 679, in __getitem__
    raise KeyError(key) from None
KeyError: 'YOLO'

I have no idea what is going wrong

As you can see, when I try to compile the cairo file, it show with these error. I tried to search on Google but can't find with any ideas. I think it's out of my knowledge, anyone know how to solve this? Thank you.

Fixes #53

Plugin support for Nile

In this PR I present a methodology for extending CLI functionality for Nile in a Pythonic manner to ease Nile extensibility with plugins.

How is this implemented?

This implementation takes advantage of the native extensibility features of click. Using click and leveraging the Python entrypoints we have a simple manner of handling extension natively on Python environments through dependencies. The plugin implementation on Nile looks for specific Python entrypoints constraints for adding commands.

In order for this implementation to be functional, it is needed by the plugin developer to follow some development guidelines defined in this simple plugin example I've implemented extending Nile for a dummy greet extension. In a brief explanation the guidelines are as follows:

1. Define a Python module that implement a click command or group:

# First, import click dependency
import click

# Decorate the method that will be the command name with `click.command` 
@click.command()
# You can define custom parameters as defined in `click`: https://click.palletsprojects.com/en/7.x/options/
def my_command():
    # Help message to show with the command
    """
    Subcommand plugin that does something.
    """
    # Done! Now implement your custom functionality in the command
    click.echo("I'm a plugin overiding a command!")

2. Define the plugin entrypoint. In this case using Poetry features in the pyproject.toml file:

# We need to specify that click commands are Poetry entrypoints of type `nile_plugins`. Do not modify this
[tool.poetry.plugins."nile_plugins"]
# Here you specify you command name and location <command_name> = <package_method_location>
"greet" = "nile_greet.main.greet"

3. Done!

How to decide if I want to use a plugin or not? Just install / uninstall the plugin dependency :)

Cheers.

I have python 3.10 installed with conda (conda create --name py310 python=3.10; conda activate py310) After installing nile and running nile init, I get

  Running setup.py install for greenlet ... error
  error: subprocess-exited-with-error
  
  × Running setup.py install for greenlet did not run successfully.
  │ exit code: 1
  ╰─> [17 lines of output]
      running install
      running build
      running build_ext
      building 'greenlet' extension
      creating build
      creating build/temp.linux-x86_64-3.10
      gcc -pthread -B /home/samlaf/anaconda3/envs/py310/compiler_compat -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -fPIC -O2 -isystem /home/samlaf/anaconda3/envs/py310/include -fPIC -O2 -isystem /home/samlaf/anaconda3/envs/py310/include -fPIC -I/home/samlaf/devel/starkware/nile-test/env/include -I/home/samlaf/anaconda3/envs/py310/include/python3.10 -c greenlet.c -o build/temp.linux-x86_64-3.10/greenlet.o
      greenlet.c: In function ‘g_calltrace’:
      greenlet.c:566:10: error: ‘PyThreadState’ {aka ‘struct _ts’} has no member named ‘use_tracing’; did you mean ‘tracing’?
        566 |  tstate->use_tracing = 0;
            |          ^~~~~~~~~~~
            |          tracing
      greenlet.c:569:10: error: ‘PyThreadState’ {aka ‘struct _ts’} has no member named ‘use_tracing’; did you mean ‘tracing’?
        569 |  tstate->use_tracing = (tstate->tracing <= 0 &&
            |          ^~~~~~~~~~~
            |          tracing
      error: command '/usr/bin/gcc' failed with exit code 1
      [end of output]
  
  note: This error originates from a subprocess, and is likely not a problem with pip.
error: legacy-install-failure

× Encountered error while trying to install package.
╰─> greenlet

note: This is an issue with the package mentioned above, not pip.
hint: See above for output from the failure.
Traceback (most recent call last):
  File "/home/samlaf/devel/starkware/nile-test/env/bin/nile", line 8, in <module>
    sys.exit(cli())
  File "/home/samlaf/devel/starkware/nile-test/env/lib/python3.10/site-packages/click/core.py", line 1130, in __call__
    return self.main(*args, **kwargs)
  File "/home/samlaf/devel/starkware/nile-test/env/lib/python3.10/site-packages/click/core.py", line 1055, in main
    rv = self.invoke(ctx)
  File "/home/samlaf/devel/starkware/nile-test/env/lib/python3.10/site-packages/click/core.py", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/home/samlaf/devel/starkware/nile-test/env/lib/python3.10/site-packages/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/samlaf/devel/starkware/nile-test/env/lib/python3.10/site-packages/click/core.py", line 760, in invoke
    return __callback(*args, **kwargs)
  File "/home/samlaf/devel/starkware/nile-test/env/lib/python3.10/site-packages/nile/cli.py", line 61, in init
    init_command()
  File "/home/samlaf/devel/starkware/nile-test/env/lib/python3.10/site-packages/nile/core/init.py", line 19, in init
    install()
  File "/home/samlaf/devel/starkware/nile-test/env/lib/python3.10/site-packages/nile/core/install.py", line 10, in install
    subprocess.check_call(
  File "/home/samlaf/anaconda3/envs/py310/lib/python3.10/subprocess.py", line 369, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/home/samlaf/devel/starkware/nile-test/env/bin/python3', '-m', 'pip', 'install', 'cairo-lang', 'starknet-devnet']' returned non-zero exit status 1.

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

Fixes #98. This PR implements the status command to fetch the status of a StarkNet transaction and the ability to wait for its settlement before initiating another transaction.

See discussion in #98. Follow up of #70, #90.

The PR splits features currently available in nile debug and implements them in other functions to be used in different cases:

• From any transaction hash, query its result. nile status <transaction_hash>.
• If the transaction may not be settled at calling time and the user wishes to wait (and get that status) before continuing, the --track flag can be added. status will then retry on pending transactions until they are REJECTED or ACCEPTED IN L2.°
• If users would like to debug the transaction message in case of rejection, use the --debug flag.
  Note that --debug implies --track. The debugcommand keeps the same functionality and is effectively an alias for status --debug.

Furthermore, nile invoke, nile deploy, nile declare Account.send, and Account.deploy can now also use --track and --debug. In that case, the process (terminal or within run) will not return before the transaction is settled (helping the fight against "nonce").

status, as well as nile invoke and account.send when these flags are used, returns a TransactionStatus, named tuple holding the transaction hash, the transaction status, and the eventual error message. Currently, deploys return value is kept unchanged.

° An additional flag --wait-for-l1 was also on my mind but I didn't think it was necessary for now.

Hi,

I'm on macOS Big Sur, and there is some system process running at port 5000. Cause of which, nile node fails to run.

Is there a way to specify the port in nile node ?

This PR proposes to add the nile-account flag to account.declare which will create an overriding_path to Nile's precompiled artifacts. This will remove the need to manually set the path for Account declarations.

Nile account declarations will look like this:

out = await account.declare("Account", nile_account=True)

as opposed to something like:

overriding_path = ("env/lib/python3.9/site-packages/nile/artifacts", "env/lib/python3.9/site-packages/nile/artifacts/abis")

out = await account.declare("Account", overriding_path=overriding_path)

Resolves #309.

Update

In the event that an issue arises from the Account contract itself, the PR will now find the artifact in Nile's own artifacts directory. In most cases where errors occur from the contract(s) called from an account, Debug will return the underlined code where the error is coming from in the contracts. The errors referenced specifically in Account will not return the underlined Cairo code because Debug needs the actual .cairo contract to reference.

This PR also proposes to:

• Improve the triggered account deployments for methods requiring an account such as deploy, declare, and send. Previously, these deployments would fail but the account would still be registered. This is because the CLI only passed watch_mode to the account method and not the account initialization/deployment.
• unregister failed account deployments. Though, it may be useful to keep the account information, I think it's possible that confusion may arise from having the account information when its deployment failed. If it's preferred to leave the data, we can remove the unregister quite easily.

Resolves #297.

The current flow of network handling creates the awkward issue of an unresolved query in perpetuity when the node.json exists but the network key does not. This PR, therefore, proposes to add goerli2 and integration gateways to the node.json in the nile node command. This means that the goerli2 and integration gateways will be accessible irrespective of the node.json file's existence.

Fixes #130

Still WIP update of nile for cairo 0.9.0

• Registers class hash declarations in a declarations.txt file
• Add max_fee param to both nre and cli as per this PR
• Add --accounts param to node command

Let me know what else should be added.

After run `nile node', it will display a lot of error:

....... File "/Users/x/Dev/my-project/env/lib/python3.8/site-packages/click/core.py", line 1657, in invoke return _process_result(sub_ctx.command.invoke(sub_ctx)) File "/Users/x/Dev/my-project/env/lib/python3.8/site-packages/click/core.py", line 1404, in invoke return ctx.invoke(self.callback, **ctx.params) File "/Users/x/Dev/my-project/env/lib/python3.8/site-packages/click/core.py", line 760, in invoke return __callback(*args, **kwargs) File "/Users/x/Dev/my-project/env/lib/python3.8/site-packages/nile/cli.py", line 193, in node node_command(host, port) File "/Users/x/Dev/my-project/env/lib/python3.8/site-packages/nile/core/node.py", line 21, in node subprocess.check_call(["starknet-devnet", "--host", host, "--port", str(port)]) File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/subprocess.py", line 364, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['starknet-devnet', '--host', '127.0.0.1', '--port', '5000']' returned non-zero exit status 1.

OS: macOS 12.3.1 (m1)

Resolves #284.

This PR proposes to automatically estimate the max_fee when the max_fee isn't explicitly passed (which would be interpreted as 0). The fee estimation logic lies in estimate_fee_when_zero.

Some notes:

CLI

• estimate_fee_when_zero precedes tx.execute in the run_transaction function.

NRE

• The NRE includes a new method execute_tx which estimates the fee (if zero) and executes the transaction. If accepted, the proposed changes will then offer users two ways to script account txs:

    await nre.execute_tx(
        account.send(ETH_TOKEN_ADDRESS, "transfer", [recipient, *amount])
    )

    OR:

    tx = await account.send(ETH_TOKEN_ADDRESS, "transfer", [recipient, *amount])
    max_fee = await tx.estimate_fee()
    await tx.update_fee(max_fee).execute()

The StarkNet network will correctly reject an attempted deployment of a duplicate contract address. account.deploy unregisters deployments upon tx rejections; therefore, if account.deploy rejects a duplicate deployment, it will unregister the successful deployment as well. This occurs because the to_delete variable looks for the address or class hash of the entry.

A potential fix might include checking if the address or class hash already exists in register. Currently, it only checks for duplicate aliases. See https://github.com/OpenZeppelin/nile/blob/main/src/nile/deployments.py#L13-L15

Another idea might consist of waiting for the tx status before registering contracts.

Maybe both?

Currently, we are handling some exceptions in code shared between CLI and NRE as if they were used only in CLI (logging and returning empty output). For example:

https://github.com/OpenZeppelin/nile/blob/6643bcd31d1826fb777a2d52c9ce5b7aef67ffa0/src/nile/core/call_or_invoke.py#L42-L65

When account.send is called from scripts, if an exception occurs, the call will return an empty response, and the exception won't be raised. This can make the user confused about what is happening, as he probably won't be checking the logging output in a script.

I think we should, as a general rule, avoid try-catching and logging outside the CLI.

Also, I think it would be helpful to implement a class handling exceptions for the CLI as a centralized entity instead of different try/catches in multiple places.

This is helpful for UX and code maintainability and extensibility.

EDIT: The code preview is not showing all the lines I wanted, but if you go to that section, and check the catch block, you will see the empty return.

EDIT 2: I think this could relate to handling watch_mode in NRE (see this issue).