Package
  • Print
  • Share
  • Dark
    Light

Package

  • Print
  • Share
  • Dark
    Light

Packages

A Package is the main entity that holds all of the entities together.
The Package is a static code with a schema that holds all the modules, functions, and the code-base from which they can be taken.
The Package entity also stores the revision history of itself, allowing services to be deployed from an old revision of a Package.
A Package is split into Modules(not to be confused with Python modules).
For each Module, the Package specifies where the entry point of the Module within the Codebase is, as well as how to load it and the configuration by which the Module should be loaded, and how the Class's functions should be run. More on modules.
package.png

Only project members with the role "Developer" or "Project Owner" can push/delete a package.

Versioning

Packages have a versioning mechanism.
This mechanism allows you to deploy a Service from an old revision of the Package.
Every time you modify the package attributes or codebase by pushing a package or by performing package.update(), a new version of this package is created. The package revisions field contains a list of all prevision states of the Package.
If the codebase has no changes, you can use package.update(); if not, you need to push a new one.
When you deploy a Service you can specify a specific revision from which to deploy the Service, the default is the last update.

If the codebase has no changes, you can use package.update(); if not, you need to push a new one.

package version.png

Modules

Not to be confused with Python modules

Modules are a reference to a Python file containing the python class (ServiceRunner by default) with functions inside it.
module.PNG

The idea behind separating a package into modules is to allow users to develop many different services that share some mutual code using one codebase. This means you can translate and define the code-base or a substance of it to a service, without needing a new code-base.
module2.PNG
Using the module you can load a model on the service deployment and then run any function that references it (see the init method for reference), or proceed to the next step in the pipeline.
A Module contains 2 fields that determine which code within the Codebase to load, initialize and run.
The fields are "entryPoint" and "className".

Module.gif

The Entry Point

The entry point is the name of the Python file containing the class and functions of the package code. It should end with .py. The default entry point is main.py.
The entry point specifies the relative path from the CodeBase root to the main file that should be loaded when loading the Module.

The Class Name

The "className" specifies the name of the python class within a file that should be loaded in the Service. The class referenced by "className" must extend dl.BaseServiceRunner in order to work.
The python class (ServiceRunner by default by you can name it however you like. just change the class_name attribute of the Package's Module) will be loaded when the service is deployed, see the init method for reference.

Module JSON

A module does not have its own JSON file. The basic scheme looks like this:

{
  "name": "default_module",    # module name
  "className":"ServiceRunner", #optional
  "entryPoint": "main.py",     # the module entry point which includes its main                                                            class and methods
  "initInputs": [],            # expected init params at deployment time
  "functions": [               # list of module functions that can be executed                                                                   from remote
                {
                "name": "run",          # function name - must be the same as the                                                                             actual method name in signature
                "description": "",  # optional -  function description
                "input": [          # expected function params
                {
                "name": "item",     # input name - identical to input param name                                                                             in signature
                "type": "Item"      # Item / Dataset / Annotation / Json
                }
],
  "output": []                      # not implemented - keep blank
}
]
}

Class Functions

This is the basic running unit of the FaaS. You can define the functions on the class and when the service is deployed, you can run each of them.

function.PNG

Class Functions Input types

Each of the function's inputs has a name and a type.
Input types can be grouped into 2 categories:

  • JSON - this allows the function to receive all possible inputs as well as having no prepossessing done by the runner.
  • Dataloop types("item", "dataset", etc...) - When invoking the function, the ID of the resource should be passed as an input. See the types reference in the repositories.

Package JSON

{
  "name": "default_package",
    "modules": [
      {
        "name": "default_module",
        "className":"ServiceRunner",  
        "entryPoint": "main.py",
        "initInputs": [],
        "functions": [
          {
            "name": "run",
            "description": "this description for your service",
            "input": [
              {
                "name": "item",
                "type": "Item"
              }
            ],
            "output": []
          }
        ]
      }
    ]
}
Was This Article Helpful?