AWS IoT Device SDK for Python V2

[rpcme]

Implement recipe for AWS IoT Device SDK for Python V2

https://github.com/aws/aws-iot-device-sdk-python-v2

[dremsol]

@rpcme, would love to see this recipe become available, is there a timeline for this? Are contributions appreciated?

[rpcme]

Hello @wremie -

Most likely it will be added the first part of Q2. We are really focused on the Device SDK C++ v2, Device SDK Embedded C, and the continuous integration automation for the rest of Q1. Device SDKs are looking to be the priority right now, with AWS SDKs after that, and then KVS libraries as well as device defender come after that.

Yes we take contributions and love them! we are starting to organize SDK recipes under recipes-sdk/ so the directory where this recipe would be is recipes-sdk/aws-iot-device-sdk-python-v2.

Also, we have developed automation to account for base repo and submodules when git is being used so all tagged releases can be build by user defined version number. In most cases, we find that an automation base can build all or most of the versions. We then organize per version files as normal with ${PN}_${PV}.bb and include file ${PN}.inc. As you can see from the Neo recipes, we will have some rework to do there to meet this pattern :).

Let me know if you have any questions ok?

[dremsol]

Hi @rpcme ,

Although being broken, I've seen the aws-iot-device-sdk-cpp-v2_1.5.2.bb recipe in zeus branch. If I understand your message correctly. This recipe is under active development?

building aws-iot-device-sdk-cpp-v2_1.5.2.bb is not a problem. However the I'm not sure how you would like the runtime dependency to be implemented as the library depends on awscrt. This package can be either build from pypi or from source. Considering that the source depends on submodules and you are speaking about some developed automation to take care of this is probably the preferred method.

How does this automation look like? I guess we need a separate recipe for awscrt just as for cpp? Although I would be able to build this recipe I'm not sure if this will be according to your automation envisioned.

[rpcme]

Yes, the cpp sdk is under active development. My workstation had been "under the weather" for a few days so I have now been able to appropriately respond.

I made a note in your PR about the common runtime. I think semantically it works right now, so let's work together on that approach moving forward.

A new repo will be created called 'meta-aws-auto' which isn't a metadata layer but just a repo for automation scripts. This will also contain automation for the continuous integration harness.

I am trying to recover from my workstation "under the weather" event and catch up on things, and will hopefully get back to it at the end of this week.

[rpcme]

I will keep this issue open until there is a chance to get together documentation for the recipe.

[rpcme]

Thank you for your contribution! The automation repo is in process of being reviewed, it should be called 'meta-aws-auto' so please watch out for it.

[mkozjak]

@rpcme, should this work under Yocto Warrior too? Tried editing deps to allow warrior and it did build and import correctly in my rpi application...

[rpcme]

@mkozjak it should since v2 supports older Pythons but I have not tried it. I am on vacation this week so I cannot cross check but I would like to hear feedback on it if you try.

[mkozjak]

@rpcme, tried and it works! Do some checks before including it if possible, though!

[mkozjak]

@rpcme, should we add warrior to LAYERSERIES_COMPAT_meta-aws to move forward with this?

[rpcme]

Hello @mkozjak - sorry for the delay, same as the other issues response, I had been on leave.

I will create a warrior branch given there are yocto project incompatibilities with zeus/dunfell. It will happen later today.