Merge this repo with the original Tessel CLI about t2-cli HOT 8 CLOSED

@rwaldron at the last Steering Committee meeting, @tcr and @Frijol brought up that you feel like we should not merge this repo with the original tessel repo. Can you share your thoughts here when you get a chance?

from t2-cli.

Sure, maybe some of my concerns can be answered:

• Firstly, there is no clear definition of what it means to "merge" these two, both on the repository level and the actual tool level.
• Will there be two code paths?
  • Will dependencies for both versions be installed? What about conflicting versions?
  • What is the plan, or expectation, for maintaining tooling for both code paths?
• Will t2 simply replace the the Tessel 1 CLI code under a new tag?
  • Will there still be maintenance on the Tessel 1 CLI code?
• What about the entire git history?

If I think of more, I will update

from t2-cli.

Cool, I think I can answer those although I have admittedly not thought this through completely yet.

What I had in mind was that we would create a new repo, called tessel-cli. It would have the t1-cli and this t2-cli as submodules. This parent tessel-cli would be the one that gets published to npm as tessel. We will need to move the logic that determines which tessel to use into this parent CLI. Whenever a command gets run like tessel run X, the code that determines which Tessel to use will get run, and if it's a tessel 1, it will shell off to the t1-cli submodule, otherwise, it goes to the t2-cli submodule.

And now that I'm thinking this through, we'd also have to move the list functionality to this parent module....

from t2-cli.

We will need to move the logic that determines which tessel to use into this parent CLI.
...
And now that I'm thinking this through, we'd also have to move the list functionality to this parent module....

Which means supporting two code paths for each, right? Because you need both T1 and T2 operations for listing and detection/selection, right?

from t2-cli.

I can imagine the parent CLI just asking both the t1-cli and t2-cli to report any connected devices. Those code paths already exist in each CLI independently (even though the t1 detection is a subset of t2 detection (only USB, no LAN)).

We could also just start publishing t2-cli as tessel once T2s start shipping and increment the major number of the package version. The t1-cli can be published as t1-cli as well.

from t2-cli.

So if the detection and listing operations move from t2-cli, then it's no longer something that can be used standalone?

from t2-cli.

Potentially.

Another option is to let both the t1-cli and the t2-cli have independent scanning/selection processes and just have the parent CLI prefer one or the other.

Again, I'm not 100% confident this is the right thing to do, just trying to work through the options.

from t2-cli.

Closing this since... well... we don't really need to do it.

from t2-cli.