Releasing Packages

• Theory
• Practice
• Alternatives
  • Rez and Continuous Integration
  • Rez and Esoteric Packages

Theory

Releasing a package is a combination of (1) making it available for others and (2) ensuring that each version is immutable in a multi-site, collaborative environment where two or more developers may attempt to release packages at once.

(2) leverages Git as a central source of truth, where the assumption is that every developer works off of a single Git repository manager - such as GitLab - and pushes/pulls code from it. This central Git server is then queried and written to during a release, to ensure no version is released twice.

Development typically happens like this.

1. You have an idea for a feature or bugfix
2. You clone
3. You edit
4. You rez build and rez build --install until you're happy
5. You rez release

Once released, your package will be taken into account the next time anyone runs rez env.

Released packages end up in a separate directory to locally installed packages, as determined by your REZ_RELEASE_PACKAGES_PATH environment variable or rezconfig.py:release_packages_path variable.

• See Configuring-Rez#release_packages_path

Practice

To ensure immutability and uniqueness, a release is associated with a Git tag. The idea is that every developer in your team share a common, global Git remote - like GitLab - and that tags are universally unique.

Releasing a package looks like this.

$ cd my_git_repo
$ rez release
...

From there, a few things happen.

1. If your local git repo has un-committed changes, the command will fail
2. If your local git repo isn't up to date with the default remote, the command will fail
3. If the version of your package.py already exists as a tag on your remote, command will fail
4. A new tag is made and pushed to our default remote
5. A local build is made
6. A release is made

Alternatives

As you've seen, release makes a number of assumptions about how your work.

1. You develop a package from a Git repository
2. You use Git tags as version numbers
3. You have a single, shared Git repository manager, such as GitLab
4. You make releases from your local machine (e.g. you do not release via continuous integration)

Sometimes, one or many of these are untrue.

Rez and Continous Integration

For example, if you use GitLab and would like to deploy packages by (1) making a tag which (2) triggers continuous integration, then rather than calling release you can override build with a --prefix

From your .gitlab-ci.yml, rather than calling rez release, you can do this.

$ rez build --install --prefix /central/packages

Since the command is triggered from a tag, this is then equivalent to locally calling rez release, with the same kind of safeguards with regards to uniqueness.

Rez and Esoteric Packages

Other times, a Rez package isn't your regular Git project. For example, if your package represents a show.

package.py

name = "alita"
version = "1.0.0"
requires = [
  "facility>=0.1",
  "core_pipeline>=1.3"
]

Or global variables for your facility.

package.py

name = "facility"
version = "0.2.1"

def commands():
  env["GITLAB_URL"] = "https://gitlab.mystudio.com"

Whereby both of your esoteric packages are stored and managed as e.g. directories on a shared network drive. Like with continuous integration, --prefix can avoid the need for the package to have any connection to Git or tags.

Build locally

$ cd facility
$ rez build --install

"Release"

$ cd facility
$ rez build --install --prefix //server/packages