In this document we are giving our test results and informations for each version of client. Some versions are not in here because they dont have any changes to our serialization mechanism.

​

0.20.3

The Patches are:

• The python version check system fixed, now the client warnings about not same minor python version situations.

The Limitaions are:

• Depth of Local .py Files Dependent on Your Function
  In this scenario, when you use multiple layers of depth for your function with local .py files, it is not supported. However, if there is only one dependent .py file, Upsonic can manage this seamlessly for your function.

  • my_function.py
  • my_sub_function.py | Supported
  • my_sub_sub_function | Unsupported

• Usage of Module-Dependent Objects in Elastic Dependencies
  When you instantiate a class object, such as a pandas DataFrame, within an elastic dependency, you cannot fully use this object in other areas, such as another elastic function or the root runtime.

• Requirement Extraction
  This is only supported for functions. Doesnt work with different name modules like PyGithub and its usage is import github.

• Extraction of Required Local .py Files
  This is only supported for functions.

• Across Python Versions
  Upsonic requires the dumper client and loader client to be running the exact same Python version, which must be 3.8 or higher.

​

0.20.2

The Patches are:

• Requirement extraction for situations like from translate import Translator (sub modules) is fixed and working now.

The Limitaions are:

• Depth of Local .py Files Dependent on Your Function
  In this scenario, when you use multiple layers of depth for your function with local .py files, it is not supported. However, if there is only one dependent .py file, Upsonic can manage this seamlessly for your function.

  • my_function.py
  • my_sub_function.py | Supported
  • my_sub_sub_function | Unsupported

• Usage of Module-Dependent Objects in Elastic Dependencies
  When you instantiate a class object, such as a pandas DataFrame, within an elastic dependency, you cannot fully use this object in other areas, such as another elastic function or the root runtime.

• Requirement Extraction
  This is only supported for functions. Doesnt work with different name modules like PyGithub and its usage is import github.

• Extraction of Required Local .py Files
  This is only supported for functions.

• Across Python Versions
  Upsonic requires the dumper client and loader client to be running the exact same Python version, which must be 3.8 or higher.

​

0.20.1

This is our suggested version for now. It’s tested with variously topics and situations.

The Limitaions are:

• Depth of Local .py Files Dependent on Your Function
  In this scenario, when you use multiple layers of depth for your function with local .py files, it is not supported. However, if there is only one dependent .py file, Upsonic can manage this seamlessly for your function.

  • my_function.py
  • my_sub_function.py | Supported
  • my_sub_sub_function | Unsupported

• Usage of Module-Dependent Objects in Elastic Dependencies
  When you instantiate a class object, such as a pandas DataFrame, within an elastic dependency, you cannot fully use this object in other areas, such as another elastic function or the root runtime.

• Requirement Extraction
  This is only supported for functions. Doest work in some situations like from translate import Translator (sub modules). Doesnt work with different name modules like PyGithub and its usage is import github.

• Extraction of Required Local .py Files
  This is only supported for functions.

• Across Python Versions
  Upsonic requires the dumper client and loader client to be running the exact same Python version, which must be 3.8 or higher.