-
Notifications
You must be signed in to change notification settings - Fork 3
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
Migration tool CLI redesign #56
Comments
Indeed there are some improvements that we can do to make the flags a bit more bearable:
The problem with the two tier structure ( We can programmatically create commands such as For legacy reasons I don't think we should remove the old |
We could add a command like $ ttn-lw-migrate use eu1.cloud.thethings.network would be pre-configured and only need to be called with minimal input |
That may also work, but in general I still recommend separating the flag sets. I think we should this Please consider doing an iteration based on what we discussed here (separation of flags and |
Summary
lorawan-stack-migrate
tool could use a different approach, mainly the flag system.Why do we need this?
The migration has been growing and the flag system is getting out of hand.
The way we implement flags currently does not support adding flags specific to a command (
![image](https://user-images.githubusercontent.com/73070465/200570593-2d1f1101-ee3b-4873-9065-709e1da2ba3e.png)
applications
,device
) or sources. This creates a lot of fuzz in the flags we present to the user that are not relevant for the current use case and it's only going to get worse:An example of this is the flag
app-id
is not needed when usingapplications
command, because theapp-id
is supplied in the command itself.Other than that
firefly
source wouldn't needapplications
command as much asorganizations
as to what I've seen that is used more often to organize devices on the platform. Because of that being able to define commands per source would be beneficial as well.What is already there? What do you see now?
We have a working CLI.
What is missing? What do you want to see?
Flexibility and structure of the CLI.
Environment
n/a
How do you propose to implement this?
Use a well developed CLI library like
spf13/cobra
and rethink the way we implement stuff.How do you propose to test this?
Test migrating devices with new CLI.
Can you do this yourself and submit a Pull Request?
I can implement this myself, but it would require help in design from a more experienced developer.
The text was updated successfully, but these errors were encountered: