finer grained install checks on greengrass lifecycle

Question

I have a greengrass component that is dependent on the awsiotsdk python module, so in the manifest we added:

```
"Manifests": [
    {
      "Name": "Linux",
      "Platform": { "os": "linux" },
      "Lifecycle": {
        "Install": {
          "RequiresPrivilege": true,
          "Script": "apt-get --yes install python3 python3-pip && pip3 install awsiotsdk",
                "Timeout" : 240
        },
```

we had to add the timeout of **240** because the install can take a long time. 
This is run each time we deploy a new version and sometimes it seems to clash with another apt install being run by a different greengrass component.

I don't  even think i need to run the install each deployment, as it should still be installed from the previous time ?
Is there a way i can split this up into the 3 different commands ?

```
apt-get --yes install python3 
apt-get --yes install python3-pip 
pip3 install awsiotsdk
```

and ignore it if it hasn't already been installed ?

In https://docs.aws.amazon.com/greengrass/v2/developerguide/component-recipe-reference.html#recipe-examples

i can see something in the **yaml** example where it does a skipif but i'm not sure how to check for awsiotsdk using this command. Are there any examples out there for a json receipe with multiples steps and a skipif ?

Greg · Accepted Answer

Hi clogwog. When the install has succeeded once, the subsequent calls to the Install lifecycle should be quick (seconds) since all packages are already installed. The **apt-get** should be reporting that **python3** and **python-pip** are `already the newest version` and likewise the **pip3** operation should report `Requirement already satisfied`. Is that not the case?

The installation of **awsiotsdk** creates files on disk of course, so you could use **SkipIf** to check for the existence of these files. However, if your component creates some other kind of file on disk after a successful Install or Run, you could check for the existence of that as a proxy (you could perhaps even do a `touch` at the end of an Install or start of a Run). [Massimiliano previously suggested using Python virtual environments](https://repost.aws/questions/QUo8qGsGcjRwWO2HYtqG8qFQ/greengrass-install-script-re-installs-pip-3-components-every-time) for this, and helping to prevent conflicts between components. I think this is a good option.

In regards to **apt-get**, if these packages are required by multiple components, I suggest you do one of the following:

1. consider installing these packages as part of your base installation and setup of the device, rather than install them from a component, OR
2. create a new component that brings this shared package management in to one place, and setup your component dependencies to make your existing components depend on this new component.

Or you could go further and containerize your components.

finer grained install checks on greengrass lifecycle

Add your answer

Relevant content