Skip to content
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

fix anchor keys list command #2063

Merged
merged 4 commits into from Dec 5, 2022
Merged

fix anchor keys list command #2063

merged 4 commits into from Dec 5, 2022

Conversation

skrrb
Copy link
Contributor

@skrrb skrrb commented Jul 15, 2022

Problem
the flag anchor keys listis intended to show (or generate if not exists) the current program pubkeys

However, since it's not ensured that the current working directory is always the top level, the behavior is not desired since it will try to create a new target folder in the invoking path

Solution
move the function to the with_workspace closure

@vercel
Copy link

vercel bot commented Jul 15, 2022

@skrrb is attempting to deploy a commit to the 200ms Team on Vercel.

A member of the Team first needs to authorize it.

@skrrb skrrb marked this pull request as ready for review July 15, 2022 11:47
@Henry-E
Copy link
Contributor

Henry-E commented Nov 28, 2022

This seems like a pretty clean fix / change to how the workspace error is triggered.

I wasn't really sure how to replicate the original buggy behaviour it's not ensured that the current working directory is always the top level, namely whatever exactly this means.

But it still looks ok, and if someone else using anchor keys list comes and complains this new behaviour messes up their program call we can just revert this PR.

@skrrb
Copy link
Contributor Author

skrrb commented Nov 28, 2022

This seems like a pretty clean fix / change to how the workspace error is triggered.

I wasn't really sure how to replicate the original buggy behaviour it's not ensured that the current working directory is always the top level, namely whatever exactly this means.

But it still looks ok, and if someone else using anchor keys list comes and complains this new behaviour messes up their program call we can just revert this PR.

oh, I'm sorry it was not clear what I mean. the issue is that if you run $ anchor keys list on any folder inside an anchor workspace, it will try to create a new target/deploy/keypair.json file instead of moving to the root of the workspace which is where right target dir is placed. For example:

$ anchor init dummy
dummy initialized
$ cd dummy/programs/dummy/src
$ ls
lib.rs
$ anchor keys list
dummy: 3XrRRGbzexwfVKjwK6cufHN1cAuRrahX1DCd2cFkANq2
$ ls
lib.rs target
       ^^^^^^ this folder should not exist

@Henry-E Henry-E merged commit fb714b9 into coral-xyz:master Dec 5, 2022
Henry-E pushed a commit to Henry-E/anchor that referenced this pull request Dec 6, 2022
* fix anchor keys list command

* changelog

Co-authored-by: henrye <henry@notanemail>
@skrrb skrrb deleted the cli-keys-list branch April 30, 2024 15:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants