Package a Build
At the conclusion of your development and testing phases, packaging your project is often necessary in preparation for publishing. While some extensions may not require this step, it becomes essential for applications and more complex extensions involving advanced features. The packaging process organizes and structures your project assets for delivery and deployment. The specifics of the packaging step depend on your desired method of distribution.
Introduction
Important Notes:
Packaging is OS dependent. Linux is required for Linux packages and Windows is required for Windows packages
Packaging requires a build of the desired Project. See Build a Project for additional details
Instructions provided here assume use of Repo tooling
Packages are a collection of all the files that compose your Project. Although it is possible to manually assemble your package by creating an archive with the necessary files and folders, Omniverse conveniently offers a more efficient alternative via the Repo Package tool. This tool verifies that you have all the essential config files and that your build folder is accurately configured.
Packaging Extensions
It’s important to note that sometimes, specifically with simpler extensions, you may only need to manually copy the files into the destination directory for distribution. Generally, the repo package method is best used for projects that contain a premake5.lua
file and result in a _build
folder.
Packaging Applications
Lock Extension Versions
Before packaging, it is advised to lock your Extension versions. While iterative development typically benefits from using the latest versions without specifying one, it’s good practice to lock Extension versions for distributed Applications. This ensures that end users install and experience the fully tested and developed version.
The following steps apply if you’re working on a Kit project that includes the Repo tool, like the kit-app-template, for example.
To lock Extension versions:
Build the Project
Open the
repo.toml
file (most likely in the root directory of the project) and insert a reference to the application.kit
file in the[repo_precache_exts]
section:
[repo_precache_exts]
# Apps to run and precache
apps = [
"${root}/source/apps/my_company.my_app.kit",
]
Run the command
repo precache_exts -u
.Open the
.kit
file. There should be a section labeledBEGIN GENERATED PART
. This is where Extension versions have been locked.
Create the Package
There are primarily two types of packages: ‘Fat’ and ‘Thin’.
‘Fat’ Package
Includes all the necessary components to run the app, encompassing both the Kit Kernel and all Extensions. This is the package type you should opt for if you don’t want end users to download anything during installation. It is particularly useful in environments without access to public repositories, such as air-gapped organizations.
‘Thin’ Package
Contains the bare essentials needed for an installation, necessitating the download of the Kit Kernel and Extensions during app installation. Thin packages optimize the use of local storage by only downloading components that other thin packaged apps haven’t already downloaded. However, this package type isn’t suitable for air-gapped environments.
Both ‘fat’ and ‘thin’ packages come as zip-archives and can be directly shared with end users.
Both fat and thin packages can be renamed - nothing inside the package depends on the package name.
Fat Package
Build the Project
Execute
repo package
.Package is created in the
.\_build\package
directory.
Thin Package
Build the Project
Execute
repo package --thin
.Package is created in the
.\_build\package
directory.
Connectors
There is no set method for packaging Omniverse Connectors. Omniverse Connectors should adhere the processes and conventions of your organization while following the instructions for integrating Connect SDK. Please ensure that you have followed the guidance for Redistributable Omniverse Software and agree to the NVIDIA OMNIVERSE LICENSING for your project.
TBD: –name package_name