If I have a list of canisters created dynamically, why do I need to have a dfx project configured to be able to delete them. This is an additional manual overhead and restriction which makes no sense.
If I am the controller principal of the canister, I should just be allowed to stop or delete the canister just as I can query the status of the canister.
This additional step is not really stopping anyone from being able to stop or delete the canister. They can easily create a mock dfx project and inject those canister ids in. But it is unnecessary and pointless.
After annoyedly () having setup the project and deleted the canister, I have my answer.
To retrieve the remaining cycle balance to the controller’s wallet, it installs a new wallet to the canister to delete, transfers it to the controller’s wallet and then removes the canister. So, basically, to transfer out the cycle balance before removing the canister.
Having understood the mechanism, it is a HACK. The management canister should be handling the cycle transfer and doing it appropriately and not relying on the user’s canister to do all the wallet canister installation shenanigans.
There’s no technical reason for that. I agree, this should be possible outside of a dfx project. You wouldn’t be able to use canister names (since those are configured on a per-project basis), but that’s no big deal. I added it to our list of annoyances that we want to fix at some point.
I agree, this would make our (dfx developers’) life easier. I’ll try to bring it up, but I suspect it won’t get changed because the current way is ‘good enough’
) having setup the project and deleted the canister, I have my answer.