-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SDK-607 feat: replace using IDs on the command line with project name #145
Conversation
815a2d8
to
62000ff
Compare
@dfinity-lab/sdk ping |
This includes install which does not take a wasm path anymore. We have a new structure for getting any metadata related to a canister, CanisterInfo. It takes a config and a name. This should facilitate working with paths and IDs in general, inside the CLI.
f32cc03
to
5c8c301
Compare
@@ -56,7 +50,7 @@ impl UserMessage { | |||
|
|||
// dfx build |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we remove this category then? create a misc one.
I'm guessing this probably uses canister names rather project name |
dfx/src/commands/build.rs
Outdated
std::fs::write(&output_wasm_path, wasm)?; | ||
|
||
// Write the CID. | ||
canister_info.create_canister_id()?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we rename the function rather than rely on a comment? I haven't looked yet but I assume that create_canister_id
mutates canister_info
or writes to dfx.json
or both.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It writes to build/<project_name>/canister.id
. I'll refactor that.
match runtime.block_on(request_status) { | ||
Ok(ReadResponse::Pending) => { | ||
eprintln!("Pending"); | ||
println!("0x{}", String::from(request_id)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we do something like this?
eprint!("Request ID: ");
println!("0x{}", String::from(request_id));
I'm hoping this would read Request ID: 0x...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same with other places we print the ID.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. Note that this code hasn't been changed (copy-pasted) and we should most definitely rewrite it all when we move the client API to the http lib.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: Should we pipe things to different stdout and stderr? Why don't we use the same (stderr)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
STDOUT is scriptable. STDERR is human readable. This is a simplification, but in essence that's what it is. Like in our scripts we use STDOUT of a command to use request-status.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the clarification!
print_idl_blob(&blob) | ||
.map_err(|e| DfxError::InvalidData(format!("Invalid IDL blob: {}", e)))?; | ||
// Install all canisters. | ||
if let Some(canisters) = &config.get_config().canisters { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should consider showing an error saying that a canister name or an --all
flag is required. Installing all canisters when a name is omitted seems like an easy way to overwrite canisters by accident.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
|
||
@test "build outputs the canister ID" { | ||
assert_command dfx build | ||
[[ -f canisters/hello/_canister.id ]] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Post this PR: Perhaps we should have a random name project test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We will change the project name soon, so let's do that then.
|
||
let canister_name = args.value_of("canister_name").unwrap(); | ||
let canister_info = CanisterInfo::load(config, canister_name)?; | ||
let canister_id = canister_info.get_canister_id().ok_or_else(|| { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also was done in #147 😁
👍
canister_info.get_canister_id_path(), | ||
canister_info.generate_canister_id()?.into_blob().0, | ||
) | ||
.map_err(DfxError::from)?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
// Generate a random u64. | ||
let time_since_the_epoch = SystemTime::now() | ||
.duration_since(UNIX_EPOCH) | ||
.expect("Time went backwards."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😁 It can happen actually.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cannot happen with UNIX_EPOCH. Only if I take now()
.duration_since(UNIX_EPOCH) | ||
.expect("Time went backwards."); | ||
let cid = u64::from(time_since_the_epoch.as_millis() as u32).shl(32) | ||
+ u64::from(thread_rng().gen::<u32>()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need the time here actually?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so we get a u64?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because we want a monolithically increasing number that is different for each run, but in case 2 runs happen in the same millisecond we want different IDs (hence the randomness).
@@ -66,6 +67,9 @@ impl UserMessage { | |||
UserMessage::StartNode => "Starts the local network client.", | |||
UserMessage::NodeAddress => "Specifies the host name and port number to bind the frontend to.", | |||
UserMessage::StartBackground => "Exits the dfx leaving the client running. Will wait until the client replies before exiting.", | |||
|
|||
// misc | |||
UserMessage::CanisterName => "Specifies the canister name. If you don't specify this argument, all canisters are processed.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hansl looks like this needs updating because of the change to require a canister name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
.arg( | ||
Arg::with_name("all") | ||
.long("all") | ||
.required_unless("canister_name") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need a similar change for the canister_name argument to say it's required unless the all flag is passed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apparently it doesn't matter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How so?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The message to the user is the same. ¯_(ツ)_/¯
…#145) * feat: replace using IDs on the command line with project name This includes install which does not take a wasm path anymore. We have a new structure for getting any metadata related to a canister, CanisterInfo. It takes a config and a name. This should facilitate working with paths and IDs in general, inside the CLI. * fixup, including fixing bash using stderr and stdout for request id * fixup: add --all * fixup
This includes install which does not take a wasm path anymore.
We have a new structure for getting any metadata related to a canister,
CanisterInfo. It takes a config and a name. This should facilitate
working with paths and IDs in general, inside the CLI.
Fixes SDK-607