Skip to main content

Private packages

Private packages can be pre-built wheel files (.whl) or buildable directories of Python files.

When you upload your private Python packages to Modelbit they become available to be installed by any of your deployments.

tip

Private packages are stored in git. That means you can add new versions of packages while on a branch and test them before merging the changes to main.

Adding packages

You can add your private packages via the Modelbit Package CLI or Python API:

modelbit package add /path/to/my_package

The /path/to/my_package should be either a .whl file or a buildable directory containing the setup.py or pyproject.toml.

Buildable directories include a config that specifies a name, version and dependencies in a setup.py or pyproject.toml. The modelbit package will build your directory with python -m build before uploading the package to your workspace.

Using your package

Like any other Python package, you can specify your private packages as dependencies of your deployment.

When using git, specify your package as a dependency in your deployment's requirements.txt:

requirements.txt
my_package==1.2.3

Private packages are installed during environment creation.

Overwriting existing versions

To help prevent mistakes, Modelbit will prevent package updates from overwriting existing versions. If you want to overwrite an already-added private package with the same version, use the force parameter:

modelbit package add --force /path/to/my_package

The next time you deploy, the newly added version of the package will be used during installation. You can automatically update existing deployments by toggling the "Redeploy" setting within the Common area of Modelbit.

Using uploaded packages

No code changes are needed to use your private packages from within a Modelbit deployment. They get installed into your deployment's environment just like you'd install them locally. That means your existing source code can continue to use the import my_package and from my_package import foo import formats with your inference function:

source.py
from my_package import foo

def predict(a: int):
return foo(a)

Testing and debugging packages

While developing a package you should test that your package builds with the expected files inside of it. First, cd into your Python package's directory.

To test that the package can be built, use the build command:

python3 -m build

You should see output like the following:

* Creating venv isolated environment...
* Installing packages in isolated environment... (setuptools >= 40.8.0, wheel)
* Getting build dependencies for sdist...
...

After the first successful build you should check that the expected files are within the package. An incorrect configuration can lead to a built package without any of your Python code inside of it. After running the build command above, unzip the dist/<your_package>.whl file and look inside. If you don't see the files you expect then something is wrong with the build configuration.

Some common setup.py configuration issues include:

  • The packages= line doesn't look like packages=find_packages()
  • Some directories of source files do not have an __init__.py.