Please give us `icp init` for existing folders

Developers Command Line Tools
1

From my experience, builders don’t start a project with the command line.
It starts by creating a folder in Finder or Explorer, and by adding different elements into it. Documents, specs, notes, screenshots, quotes, designs, images, prompts, …

Only then, when you have a clearer view on the project, you add the folder in your IDE, chose your stack and start developing.

For now, there is no simple icp init command to run in that existing folder.
Sure, icp new <project-name> --init is the actual equivalent, but it’s not intuitive… you’re already inside a named folder, yet you still have to pass a <project-name> argument that means nothing in that context.

Each time I’m on that phase I rage inside wondering why this first step is already a pain :D.

The first command should be intuitive, and icp init would be the expected standard.

Pleaaaazzzzzz :slight_smile:

2

Good idea. Would be handy.

3

There is already icp new --init. It does exactly what you want :slightly_smiling_face:

4

Thanks @Vivienne, but no.

  1. Your answer is not just dismissive, it is factually NOT true.
    icp new --init does not work without arguments.

1068×208 31.9 KB

The <NAME> argument is required, you are forced to redundantly name a folder you’re already standing in.

But even if the <NAME> argument was not required, that’s not initializing in place — that’s icp new with an extra step. This is exactly my point.

  1. The issue isn’t functionality, it’s discoverability and convention.

When a developer is standing in an existing folder and wants to initialize a project, they will instinctively type icp init, because that’s what every major tool in the ecosystem does:

Tool New folder Existing folder
git git init <dir> (optional arg) git init
npm — npm init
cargo cargo new cargo init
docker — docker init
hardhat — npx hardhat init
forge forge init <dir> (optional arg) forge init
icp icp new icp new --init <project-name> :cross_mark:

cargo makes the distinction explicit and clean: cargo new creates a directory, cargo init works in place. Two verbs, zero ambiguity.

The verb new will never be what a developer reaches for when standing in an existing folder.

icp init — no arguments, in place. That’s all we’re asking for.

5

@jdelforge with the latest icp-cli version you should be able to use icp new --init :wink:

see CLI Reference | ICP CLI

edit:

  • I just saw that @Vivienne already answered that back then. maybe you didn’t update the icp-cli or the feature was only active on main at this point of time. however, I just tested the command and it definitely works
6

@marc0olo Indeed, I can now see icp new --init working. Not sure what happened previously. I checked carefully but eventually not on the latest version. Sorry about that @Vivienne, you may have found my reply a bit mad. I still believe icp init would be beautiful, but that’s ok I guess.

7

it was a conscious decision not to add a new command just for this feature, but indeed it should be supported.

maybe you just want to create your own alias locally :wink:

8

canic v0.35.4 will have more fleet management features. It wraps icp-cli and keeps the yaml file in check, so you can mix and match standalone canisters and canic fleets.

image
image800×712 26.5 KB

NOTE: THIS IS POWERFUL SOFTWARE AND THE FOUNDATION ARE TRYING TO BURY IT. YOU MAY HAVE TO WEAR SPECIAL SUNGLASSES TO SEE THE TRUTH.

9

image
image549×432 7.07 KB

Look at those lovely wasm sizes!

image
image722×261 12.5 KB

canic.toml config, and you can view it via the CLI

image
image1073×578 38.4 KB

So yeah please keep up the icp-cli work, love it so far!

10

It also adds one or two endpoints for you. Root comes with every feature installed by default as it’s the fleet orchestrator. Maybe this needs a bit of a trim to be honest lol.

Anyway, the point is you don’t need to use icp-cli any more if you’re working on a project that scales past a single canister. That is my aim anyway.

image
image1092×850 50.2 KB

11

Even Docker changed their mind at some point, and finally released docker init :slight_smile: .

12

Icp-cli itself has a tremendous amount of args and things that make it kinda unintuitive. Maybe I’m just not smart and stuck in dfx ways but I hope dfx is supported longterm.

13

can you elaborate on what exactly is unintuitive from your point of view?

dfx is already considered deprecated as we speak, so that is highly unlikely to happen. it doesn’t make sense to maintain both tools going forward.

14

A couple things,

The need to create an icp.yaml directory for calls, some of the new formatting changes like “detached” canisters. It’s just subtlies but like I said I’m not sure if I am a curmudgeon whom is stuck in dfx ways and I will get used to it; or if it really feels like a whole new process for interacting with the ic.

I’m using the -help flag a lot. I will say that the dfinity skills for ai is really a tremendous help for migrating to icp cli.

15

that is not correct, you can make canister calls to mainnet outside a project context when using -n ic option.

example to fetch ICRC1 metadata from the ICP ledger from any location in your terminal:

icp canister call ryjl3-tyaaa-aaaaa-aaaba-cai icrc1_metadata '()' -n ic

the --detached option is mostly relevant if you want to create a canister outside of a project.

:+1:

if --help is not detailed or clear enough for some commands, let us know. this is also relevant for AI agents to get accurate instructions using that command.

16

TAKE WITH PINCH OF SALT - BEEN WORKING ALL DAY WITH THIS LLM AND ASKED IT FOR ADVICE ON WHAT IT NEEDED. MAY BE HALLUCINATING

Could ICP CLI expose stable machine-readable results for automation?

For tools like Canic, the biggest pain is that we need to drive icp as an
operator backend: create snapshots, upload/restore them, inspect canister
state, resolve environments, and record durable receipts. When output is
human text/tables, downstream tools have to scrape it, which is brittle.

Top requests:

  1. Add stable --json receipts for mutating operations, especially
    snapshots.
icp canister snapshot create root -e local --json
icp canister snapshot upload root --input backups/root.snapshot -e local

The output should include fields like ok, canister_id, snapshot_id,
operation, started_at, completed_at, and structured error codes.

  1. Make canister calls return structured JSON with transport metadata
    separate from decoded reply data.

icp canister call root canic_subnet_registry ‘()’ -e local --query --json

Ideally something like ok, reply, reject, canister_id, method, query, and
network.

  1. Add stable JSON for project/environment/status inspection.

icp project show --json
icp environment show local --json
icp canister status root -e local --json
icp network status local --json

This should expose environment network, canister IDs, project root, local
ports, running/stopped state, controllers, module hash, and local replica
ownership metadata.

The theme is: if a field matters operationally, expose it as structured
output so tools can use jq or normal JSON decoders instead of parsing
display text.

17

will forward the request. I guess this issue here is related in case you haven’t seen it yet:

18

Hadn’t seen it but just started work with icp-cli late last week. Love it so far.

EDIT: haha you replied to Adam and broke the rules :wink: But thanks anyway.

19

You are correct. I was conflating something I am doing incorrectly with icp-cli itself, which was a mistake. I just went back and checked to see if I could recreate my “issue” and lo and behold, it turns out that it’s simply because icp-cli is more project-root aware than dfx for my usecase I had to create fake and minimal --project-root-override in order for runners to work.

I am a fool.

20

don’t be rude to yourself, it’s a new tool :slight_smile: glad you figured it out!