Object representing an IOTile component that implements or extends CoreTools.
IOTile components are “projects” in the sense of traditional IDEs, “packages” in nodejs or “distributions” in python. They are single directories that contain related code and a metadata file that describes what the project is and how to use it.
Since IOTile components describe building blocks for IOT devies, they do not contain code in a single language but could describe a variety of different kinds of artifacts such as:
- firmware images
- python extensions for CoreTools
- build automation steps used in hardware manufacturing
- emulators for specific IOTile devices
The unifying concepts that extend to all of the above finds of components are that they product “artifacts” through a build process, the entire component has a single version and it can have dependencies on other components.
There is a single file inside the root of the component directory, module_settings.json that contains all of this metadata.
The IOTile object is constructed from a module_settings.json file and provides helper routines to parse and search its contents.
- folder (str): The path to a folder containing a module_settings.json
- file that will be loaded into this IOTile object.
The canonical list of all product types that contain python code.
This is used to know if this IOTile component will contain a support wheel, which happens if it produces any products of these types.
The canonical list of products that are stored as a list.
Most products are stored in module_settings.json in the products map where the key is the path to the product and the value is the type of product. Some products, those in this property, are stored where the key is the type of product and all of the specific products are stored in a single list under that key.
Declarations for products that require special path processing.
Parse a v1 module_settings.json file.
V1 is the older file format that requires a modules dictionary with a module_name and modules key that could in theory hold information on multiple modules in a single directory.
Load settings for a module.
Ensure that all product locations are strings.
Older components specify paths as lists of path components. Join those paths into a normal path string.
_process_product_path(self, product, declaration)¶
Search for products of a given type.
Search through the products declared by this IOTile component and return only those matching the given type. If the product is described by the path to a file, a complete normalized path will be returned. The path could be different depending on whether this IOTile component is in development or release mode.
The behavior of this function when filter_products has been called is slightly different based on whether product_type is in LIST_PRODUCTS or not. If product type is in LIST_PRODUCTS, then all matching products are returned if product_type itself was passed. So to get all tilebus_definitions you would call
By contrast, other products are filtered product-by-product. So there is no way to filter and get all libraries. Instead you pass the specific product names of the libraries that you want to
filter_productsand those specific libraries are returned. Passing the literal string
filter_productswill not return only the libraries, it will return nothing since no library is named
- product_type (str): The type of product that we wish to return.
list of str: The list of all products of the given type.
If no such products are found, an empty list will be returned. If filter_products() has been called and the filter does not include this product type, an empty list will be returned.
Return a list of directories containing any static libraries built by this IOTile.
When asked for a product, filter only those on this list.
The path to this component.