Mbed-os: Mbed CLI not in requirements.txt

Created on 12 Feb 2019  路  7Comments  路  Source: ARMmbed/mbed-os

Description

@JuhPuur brought up a good point.

Is there a reason why mbed-cli isn't included Mbed OS' requirements.txt?

@ARMmbed/mbed-os-maintainers @ARMmbed/mbed-os-tools

Original question posted here: https://jira.arm.com/browse/MBEDOSTEST-148

Issue request type


[x] Question
[ ] Enhancement
[ ] Bug

CLOSED mirrored

Most helpful comment

I'm still waiting for some grand solution that solves all this tools confusion.
Be nice if there was a really clean block diagram somewhere illustrating the current tools and their relation to the OS, target hardware, etc. and then another for a grand vision of elegance.

I still find it very hard to even describe to people what mbed-cli does other than hook up to a bunch of different tools that come from various repositories but also may or may not exist within the mbed-os source repository. But also now are being joined together into some sort of mono-repo that will be copy pasted into mbed-os/tools every so often. And then pyOCD is over here, cmsis-dap was there, now daplink for this, greentea, htrun, google test this, webdap, Python3, no python2, requirments.txt.

It's an amazing set of tools but I'm really having to pull out all the stops on my end to make it fit a process we can take advantage of.

All 7 comments

It'd be a circular dependency. Since mbed-cli uses requirements.txt to install dependencies, it would try to install itself.

Wouldn't it skip itself since it's already installed?

I suppose that would lead into a different conversation/can of worms as to if mbed-cli should be autoinstalling modules anyways.

Wouldn't it skip itself since it's already installed?

If we're pinning different versions of mbed-cli within different versions of mbed-os, that could get really hairy quickly (your version of mbed-cli constantly changing).

I suppose that would lead into a different conversation/can of worms as to if mbed-cli should be autoinstalling modules anyways.

Pretty much 馃槃

I'm still waiting for some grand solution that solves all this tools confusion.
Be nice if there was a really clean block diagram somewhere illustrating the current tools and their relation to the OS, target hardware, etc. and then another for a grand vision of elegance.

I still find it very hard to even describe to people what mbed-cli does other than hook up to a bunch of different tools that come from various repositories but also may or may not exist within the mbed-os source repository. But also now are being joined together into some sort of mono-repo that will be copy pasted into mbed-os/tools every so often. And then pyOCD is over here, cmsis-dap was there, now daplink for this, greentea, htrun, google test this, webdap, Python3, no python2, requirments.txt.

It's an amazing set of tools but I'm really having to pull out all the stops on my end to make it fit a process we can take advantage of.

I still find it very hard to even describe to people what mbed-cli does other than hook up to a bunch of different tools that come from various repositories but also may or may not exist within the mbed-os source repository. But also now are being joined together into some sort of mono-repo that will be copy pasted into mbed-os/tools every so often. And then pyOCD is over here, cmsis-dap was there, now daplink for this, greentea, htrun, google test this, webdap, Python3, no python2, requirments.txt.

Sounds like documentation improvement! We will review

Thanks for the feeback!

@0xc0170 This discussion should be happening elsewhere but, I believe most of the confusion comes from the build and config system being too tightly coupled with mbed-os.

I see and appreciate the delicate balance between making a generic tool-set for embedded development and developing an OS that is usable now.

But I still would like to see a path towards and beyond the concepts introduced by Mbed OS 3.

Was this page helpful?
0 / 5 - 0 ratings