Package

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.

Codebase

The package codebase is the code you import to the platform containing all of the modules and functions.
When you upload the code to the platform, either from your computer or from Github, it is saved on the platform as an item (in a zip file).
If you wish to download the codebase, use the following script:

# Get the service
service = dl.services.get(service_id='my_service _id')
# get the item object of the code base
code_base = dl.items.get(item_id=service.package.codebase_id)
# Download the code to a local path
code_base.download(local_path='where_to_download_the_codebase')

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.

# the package latest version
package.version
# List of all of the package versions
package.revisions

Modules

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

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.

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".

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
    # list of module functions that can be executed from remote
    "functions": [
        {
            "name": "run",  # function name - must be the same as the actual method name in signature
            "description": "",  # optional -  function description
            # expected function params
            "input": [
                {
                    # input name - identical to input param name in signature
                    "name": "item",
                    "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.

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": []
          }
        ]
      }
    ]
}