feat: local network process MGMT CLI

[antazoey]

What I did

Allows flows like this:

ape networks run --network ::node --background
ape networks list --running
ape networks ping --network ::node
ape networks kill --all

basically Ape now tracks the processes it has started and you can easily kill them all from the command line as well more easily background the processes in the same terminal session and w/o losing the PID

fixes: #2528

Also allows

with networks.parse_network_choice("pid://12345") as running_node":
    ...

For connecting to local nodes processes via PID.
Note: this process must have been started by Ape for this to work currently though.

How I did it

copied this from the dfx tool: https://github.com/dfinity/sdk

How to verify it

tbd

Checklist

• All changes are completed
• Change is covered in tests
• Documentation is complete

[fubuloubu]

Hmm, would this better unlock subprocess testing in CI? At least for the integration tests

[antazoey]

Hmm, would this better unlock subprocess testing in CI? At least for the integration tests

Probably, as it gives you more control to start up any networks you need in the beginning.. Also, you can more easily connect to providers via PID, which I want to think of a better way to incorporate that in parse_network_choice() logic, but in any case it would probably be good for silverback back testing so you can always connect to the same running fork node rather than starting up new ones constantly... you can still reset the fork to get a clean state.

[fubuloubu]

you can still reset the fork to get a clean state.

Why not have this be the default way that ProviderAPI.disconnect works with those types of forks? And then just add atexit to fully shut it down on session end (if not asked to run in background)

[antazoey]

Why not have this be the default way that ProviderAPI.disconnect works with those types of forks? And then just add atexit to fully shut it down on session end (if not asked to run in background)

Maybe when using the .fork() context, but for regular connections, you would lose your state that you probably need. Think testing bridge dApps for example... As soon as you switched to another chain, it would reset.

[antazoey]

But I agree - when using .fork(), we could incorporate this a bit... I think that is the intended use-case of .fork() so it makes sense

Also, the atexit handler is the what does call the disconnect, not exiting the context.

[fubuloubu]

But I agree - when using .fork(), we could incorporate this a bit... I think that is the intended use-case of .fork() so it makes sense

Would certainly be a lot faster testing this way vs. how I am doing backtests now w/ anvil in ApeWorX/silverback#174

Currently takes 14 mins to run 2 mins of history, so that needs to come way down

[antazoey]

Currently takes 14 mins to run 2 mins of history, so that needs to come way down

If I was you, I would already be managing the process and just connecting to it and calling reset_fork().
You can connect to it normally and call 1 method each time at the beginning of the simulation...
.fork() is the only method that completely tears down the forked network, regularly connecting won't do that.

[antazoey]

Would certainly be a lot faster testing this way vs. how I am doing backtests now w/ anvil in ApeWorX/silverback#174

In any case, this is not super related to this PR so shouldn't be blocking

[antazoey]

Testing demo:

I made a config like this:

foundry:
  ethereum:
    local:
      uri: http://127.0.0.1:5001

node:
  ethereum:
    local:
      uri: http://127.0.0.1:5000

And then these are some commands w/ output:

(apedev13) ➜  playground ape networks list --running 
Local node(s) not running.
(apedev13) ➜  playground ape networks run --network ::node --background
Making request HTTP. URI: http://127.0.0.1:5000 Method: web3_clientVersion
Starting geth (HTTP=127.0.0.1:5000, IPC=$HOME/.ape/node/geth.ipc).
(apedev13) ➜  playground ape networks run --network ::foundry --background
Starting 'anvil' process.
(apedev13) ➜  playground ape console --network ::node
(apedev13) ➜  playground ape networks list --running
PID    NETWORK                 IPC                       HTTP                   WS                 
33542  ethereum:local:node     $HOME/.ape/node/geth.ipc  http://127.0.0.1:5000  None               
33564  ethereum:local:foundry  None                      http://127.0.0.1:8545  ws://127.0.0.1:8545
(apedev13) ➜  playground ape console --network ::node
INFO:     Connecting to existing Geth node at $HOME/.ape/node/geth.ipc.

In [1]: exit
(apedev13) ➜  playground ape networks list --running 
PID    NETWORK                 IPC                       HTTP                   WS                 
33542  ethereum:local:node     $HOME/.ape/node/geth.ipc  http://127.0.0.1:5000  None               
33564  ethereum:local:foundry  None                      http://127.0.0.1:8545  ws://127.0.0.1:8545
(apedev13) ➜  playground ape console --network ::foundry

In [1]: exit
(apedev13) ➜  playground ape networks list --running    
PID    NETWORK                 IPC                       HTTP                   WS                 
33542  ethereum:local:node     $HOME/.ape/node/geth.ipc  http://127.0.0.1:5000  None               
33564  ethereum:local:foundry  None                      http://127.0.0.1:8545  ws://127.0.0.1:8545
(apedev13) ➜  playground ape networks kill                                
Stopped the following node(s):
        ethereum:local:node - $HOME/.ape/node/geth.ipc
        ethereum:local:foundry - http://127.0.0.1:8545
(apedev13) ➜  playground ape networks list --running
Local node(s) not running.
(apedev13) ➜  playground 

[fubuloubu]

Looks pretty good, just have some notes about killing process interface

[antazoey]

Looks pretty good, just have some notes about killing process interface

Feedback addressed! thank you

[antazoey]

So now you do --all to kill them all, else you have to give it one or more --pid option

[bitwise-constructs]

super helpful, nice add