Exporting library

Description of the library export functionality in Typhoon HIL Control Center

Export procedure

Libraries are saved to *.tlib files by default. These libraries can be used (loaded to a library collection) without problems as long their parent directory is added to the library search path (File → Modify library paths action). The downside of this approach is that any resource files needed by the library must be carried away with the library file independently. Also, the library content is visible, so anyone can see the library implementation.

Another approach to library deployment is to use exported libraries. Library export packs a library with its resource files (and optionally encrypts library content and locks top level library components). There is also an option of packing multiple libraries in a single export, in case they depend on each other.

Note: If a library contains a component from another user library, that library will be automatically added to the list of dependencies, and both of them will be included in the package.

Note: Dependent libraries that are exported will not be visible in Library Explorer.

Note: In order to include other *.tlib files in a multi-file library, they also have to be added to the dependency list.

To export a library choose the File → Export library action and then customize export library options using the export library dialog.

Figure 1. Library export menu action and export library dialog

Encryption management

If Encrypt resource files is checked, the Manage encryption button becomes enabled. Clicking on this button will open the Encryption management dialog.

In this dialog you can check which files/directories you want to encrypt during packaging. Files and directories left unchecked will be included without encryption.

Note: C code files (.c and .h) shouldn't be encrypted, as compilers will not be able to decrypt them later on. Instead, if you need to hide the implementation, you can precompile the code (refer to C function documentation)

Resource access

Libraries can access resources using the built-in open function, or by using external Python libraries such as pandas, json, etc. When the library is exported, resources may be encrypted. In order for everything to work with encrypted resources, there are two requirements regarding library development:

Resources need to be accessed either by using a relative path or by using an absolute path constructed from the get_library_resource_dir_path() API function.

# Correct
with open("..\resources\file.txt") as f:
    file_content = f.read()

# Correct
import os
root_path = mdl.get_library_resource_dir_path(item_handle)
file_path = os.path.join(root_path, "..", "resources", "file.txt")
                            
with open(file_path) as f:
    file_content = f.read()

# Wrong
with open("C:\library\resources\file.txt") as f:
    file_content = f.read()

If an external Python library is used for resource access, it needs to be opened using the built-in open function, and that file object should be passed as a parameter, instead of the file path, in order to handle resource decryption.

import pandas as pd
 
# Correct
with open("..\resources\file.csv") as f:
    df = pd.parse_csv(f)

import pandas as pd
                            
# Wrong
df = pd.parse_csv("..\resources\file.csv")

When using the open function, the accessed resource will be decrypted, if needed, and an in-memory file-like object (StringIO/BytesIO) will be returned in that case.

with open(...) as ... statement is also supported.

During development, the path is calculated relative to the .tlib file in which the corresponding component is defined. After export, the root for resource access will be changed, but the resource hierarchy will remain unchanged. This means every access should be the same as before export, and there is no need to make changes to the resource handling code.

Importing Python modules

Libraries can import and use Python modules in handlers. If local Python modules are used, they can be added as library resources during export, and they can be encrypted on that occasion.

In-memory decryption is supported and is done seamlessly, as long as Python files are added to the resource list during export. Both import ... and from ... import ... statements are supported.