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)

1. Create a new project by following the Getting Started steps
2. Compile the example contract with nile compile
3. I noticed that I cannot setup an account using setup due to https://github.com/OpenZeppelin/nile/issues/299, because the Account contract is not declared yet. So instead, I created a script with the following:

from nile.core.account import Account

async def run(nre):
    signer = "PRIVATE_KEY"
    account = await Account(signer, nre.network)

and ran that script with nile run <script> 4. Try to declare the contract contract with nile declare PRIVATE_KEY contract 5. The following error occurs:

🚀 Declaring contract
⏳ Successfully sent declaration of contract as 0x399998c787e0a063c3ac1d2abac084dcbe09954e3b156d53a8c43a02aa27d35
🧾 Transaction hash: 0x7217575b1175f78ff6201490887019448f5af5e20715e3513aef86d4d168112
📦 Registering 0x399998c787e0a063c3ac1d2abac084dcbe09954e3b156d53a8c43a02aa27d35 in localhost.declarations.txt
⏳ Querying the network for transaction status...
❌ Transaction status: REJECTED
🧾 Found contracts: ['0x01de4967d751b8f23da1129659357191f634c3d451a235d0dd5b2bcb9c7b1ae5:/Users/eric/git/nileproj4/env/lib/python3.9/site-packages/nile/artifacts/Account.json']
⏳ Querying the network with identified contracts...
🧾 Error message:
Requested contract address 0x1de4967d751b8f23da1129659357191f634c3d451a235d0dd5b2bcb9c7b1ae5 is not deployed.

Note that the error message's address 0x1de4967d751b8f23da1129659357191f634c3d451a235d0dd5b2bcb9c7b1ae5 is the same as the account address 0x01de4967d751b8f23da1129659357191f634c3d451a235d0dd5b2bcb9c7b1ae5 but missing a leading 0.

Additional info:

localhost.accounts.json contains:

{
  "0x7e52885445756b313ea16849145363ccb73fb4ab0440dbac333cf9d13de82b9": {
    "address": "0x01de4967d751b8f23da1129659357191f634c3d451a235d0dd5b2bcb9c7b1ae5",
    "index": 0,
    "alias": "PRIVATE_KEY"
  }
}

localhost.deployments.txt contains:

0x01de4967d751b8f23da1129659357191f634c3d451a235d0dd5b2bcb9c7b1ae5:/Users/eric/git/nileproj4/env/lib/python3.9/site-packages/nile/artifacts/abis/Account.json

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?

DISCLAIMER: I know this PR is big :(, but I felt it was necessary already when I tried to add query_flag for declare and I noticed that I probably had to duplicate methods in the current design (from send existing integration), and the NRE API UX felt bad. I feel that letting this refactor for later would have made it harder.

Fixes #308 #242

Besides adding query_flag for declare and deploy_contract, this PR proposes a refactor of the internal transaction flow of Nile, improving the NRE interfaces, and making it easier to add logic to transactions in one place, among other things...

Now NRE transaction execution commands always (must) return a transaction status, containing the tx_hash, the status of execution (ACCEPTED, REJECTED, etc...), and error messages in case of REJECTION, improving the UX. status is always used even when track or debug are not set, with the difference that it doesn't hang, but return the current status.

These are some examples of what you can do with scripting now:

# script.py
async def run(nre):
    accounts = await nre.get_accounts(predeployed=True)
    account = accounts[0]

    # get account declare wrapper
    # the wrapper is for registering deployments, or declarations, those Nile specific things
    # you could use the low level transaction to avoid this, and just execute the transaction
    tx = await account.declare("Account", watch_mode="track")

    # get the estimate fee in WEI
    fee = await tx.estimate_fee()

    # get the simulation trace in a dict
    simulation_trace = await tx.simulate()

    # execute the transaction
    # you will get the tx_status even if you pass pass watch_mode=None
    # in this case the transaction won't hang, and the status will be PENDING
    # in a testnet (probably, could be REJECTED)
    tx_status, _ = await tx.execute()
    
    # print ACEPTED_IN_L2
    print(tx_status.status)
    
    # more info in tx_status, always available after the execution
    print(tx_status.tx_hash, tx_status.error_message)

IMPORTANT: There are a lot of tests to either add, refactor or remove, then I will wait for approval of the logic before starting adding coverage. I tested the features manually before submitting them.

NOTE: The only command I haven't refactored is the deploy of the account itself, because deploy_account is not using execute_call, but calling the gateway directly. I know this is because deploy_account in starknet_cli requires a straknet account, and is not open to integrations @martriay. I would need to work in a work around for this, but I didn't want to delay this PR more. That's the only command that is not going through the new flow.

Every feedback is appreciated, I know there should be a lot of details, but I hope the idea would help us.

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).