Just saw your replies and tried it with ICP CLI version 0.3.0 and it works! 
Thanks for the quick fix, especially on a Sunday, @raymondk and @lwshang.
Use https://cli.internetcomputer.org please.
icp-cli v1.0.0 is released
Hi folks,
It’s been out for a few days already, but I’m happy to announce that icp-cli v1 is released.
Agent skills and icp-cli docs have been updated.
Highlights
For those of you who have been keeping up with icp-cli releases, you’ll find there are no big changes changes since v0.3.x and that’s exactly this point.
icp-cli is now decoupled from:
- The canister build toolchains
- The asset canister sync process
- The local network launcher
We feel confident that we’ve reached a solid config format, an interface that will remain stable for some amount of time and that we can continue to deliver incremental improvements without breaking your existing configurations and CI pipelines. That is the promise of v1.
On behalf of the DX team, thank you for the always valuable feedback,
Cheers!
Looks like icp canister delete doesn’t reclaim the remaining cycles in the canister to be deleted. Is this to be implemented or there is another preferred way to get the cycles back?
Hi @quinto,
There is an open issue for it: icp canister delete does not recover cycles (behavior differs from dfx) · Issue #431 · dfinity/icp-cli · GitHub
It is not implemented yet.
Reclaiming the cycles involves:
- installing a wasm to the canister that has a special method
- Calling the method which transfers the cycles to some account on the cycles ledger
- deleting the canister
We can probably document manual steps for now. I was waiting to see if there was something we could do at the protocol level instead of this weird process that requires computing costs etc…
Out of curiosity, why did you need to delete the canister? Why not reuse it instead?
Thanks for the explanation! It would be good to add a warning saying something “deleting a canister will forfeit its remaining cycles”, and asking user to add a flag “–force” in order to proceed.
Because there is no good way of installing a canister to an existing canister id except manually editing json file.
Also, I was under the impression that canister id itself is reserved for many years even after deletion. But seems I can no longer install a new canister to the same canister id after deleting the old one. Was I mistaken?
It’s true - you have to edit the files manually at the moment.
Would you feel more comfortable if there was a command like:
icp project set-canister-id <canister-name> <canister-id> -e <environment-name>
Once the canister is deleted, its id cannot be reused.
In general, I think of a canister on the IC as real estate. You have to spend cycles to create them and it’s better to repurpose them instead of deleting them.
. Not sure if that’d be easy, and you might have more important things to do…
Thanks @jdelforge - Made this issue: Add the ability to link a canister to a name in the NNS · Issue #620 · dfinity/icp-cli · GitHub
This might fit nicely into a NNS extension or something of the sort.
Actually @jdelforge, now that you can link a web identity to icp-cli you can already do this programmatically:
# first create an identity that is linked to your nns identity
# When you do this, you will be taken through the web flow
# If it's the first time, you will be asked to grant permission and you'll need to re-run the command
# here I picked `my-nns-identity` as an example but you're free to pick a name
icp identity link web my-nns-identity --app nns.ic0.app
# check that the identity matches, run
# you should see a principak that matches the principal you see on nns.ic0.app
icp identity list
# Switch to using that identity
icp identity default my-nns-identity
# Then you can make a canister call to the nns dapp
# the nns dapp's canister id is qoctq-giaaa-aaaaa-aaaea-cai
# You want to call the attach_canister method
# This will use the wizard and prompt you to select the method, then the arguments
icp canister call -n ic qoctq-giaaa-aaaaa-aaaea-cai
# Alternatively, you can just pass everything directly on the cli, eg
icp canister call -n ic qoctq-giaaa-aaaaa-aaaea-cai attach_canister '(record { name = "nns-dapp"; canister_id = principal "qoctq-giaaa-aaaaa-aaaea-cai"; })'
Interesting. I’ll try it out. Thanks!
@raymondk Hello thanks for your great work, as a use-case developer, i think we need compile time Environmental Variable similar to dfx. example there are part of my codes that get compiled if the network is Local(not mainet). most of the icp-cli env vars are runtime based.
Thank you
Hi @Zedonboy
One of the goals of icp-cli is to enable building once and deploying the same artifacts to different environments.
I’m going to assume that you’re asking about this for your frontend builds, please correct me if that is not the case.
As of release 0.2.7 , script s teps running in the sync phase have access to environment variables, see docs. This can be useful if you want to generate different frontend assets for different environments.
It should be noted that since the sync step runs after the cansiter wasms are installed, there is a chance that your cansiters will deploy fine, then your frontend assets fail to build and don’t get synchronized and you end up in a bit of a weird state. (You can get around this by build frontend assets in both the build and sync phase - but that’s not very pretty…)
I would encourage you to look at the hello-world templates, you can see how the canister environment variables are passed to the frontends and can be consumed at runtime.
Is there any icp-cli equivalent of
dfx canister delete my-old-canister --withdraw-cycles-to-canister my-running-canister --network ic
Regarding icp canister delete, the general docs here say
“Remaining cycles are refunded to the controller who made the delete request”.
I made a test, but couldn’t verify any return. Somehow the cycles were lost/burned.
Claude also assumed that the command would return the cycles to the cycles ledger.
I found later that the general docs contradictory say regarding the delete_canister method:
“Deleting a canister cannot be undone, any state stored on the canister is permanently deleted and its cycles are discarded”.
The icp-cli docs do not mention anything about it.
Thanks!
I’ll correct the docs.
For now deleting canisters with icp-cli DOES NOT return cycles.
We have a an open issue for it here: icp canister delete does not recover cycles (behavior differs from dfx) · Issue #431 · dfinity/icp-cli · GitHub
Also - I have the same questions for you as here:
Arg. Didn’t see it, my bad.
The problem with the idea of considering canisters as real estate is that when you have a rather large fleet (+90), the nns canisters’ view keeps on being unstable. I often get this error, not sure who to tag for this.
Aw, Snap!
Something went wrong while displaying this webpage.
Error code: 5
(seems like we cannot add screenshots on the forum anymore 
)
unfortunately that is a result of other recent forum activity.
what would you like to show in the screenshot?
can you share some more details on this and potentially your setup? where and when is that problem happening? are you saying that your local instance is crashing?
independent of that, getting cycles back when deleting a canister will soon be supported in icp-cli, see https://github.com/dfinity/icp-cli/pull/633
I think Dfinity has been going way too easy with the retarded mess in the forum. So as usual, normal citizens have to pay the price, but that’s a side thought.
__
What I would like to share is simply what I see when the error happens (the Aw, Snap! error):
https://share.zight.com/mXuL7DGE (screenshot)
https://support.google.com/chrome/answer/6098869 (chrome explanation)
https://support.brave.app/hc/en-us/articles/360018192251-How-do-I-fix-page-crashes-and-other-page-loading-errors (brave explanation)
This is happening when i manage my canisters on https://nns.ic0.app.
Exact way to reproduce:
- click on a canister
- go back to list by clicking on
button.back - canisters load, and at the end of the load (all skeletons gone), crash.
- Hitting reload shows the list of canisters again.
I have pruned my fleet down to 41 canisters, and it is still happening. It doesn’t stop any functionality, but it is constantly interrupting my workflow.
My setup is regular, powerful machine with low activity, happening on both Brave & Chrome, in both incognito and normal modes, not tied to any modem (happening in different places with different connecting setups). I’ve been experiencing this for a long time, eventually since my fleet got growing. My setup is running smooth for everything else, and I’m rather a power user.