single multi-version package file for "external" packages #54
Comments
|
Timestamping is pretty straightforward. Every package has (should have) an When you use timestamping in Rez, you are just ignoring all packages with a Anyway onto multi-version package definitions: They aren't my cup of tea personally, but as long as they were supported On Mon, Apr 28, 2014 at 6:35 PM, Chad Dombrova notifications@github.comwrote:
|
should be doable. this will take a bit more work in my schema branch to represent hierarchies of files and folders as a single schema (see issue #52). in this way a single file, like the one described here, can provide the same metadata as a tree of files.
I've created a python prototype that uses a context manager to track the overrides: name = 'maya'
config_version = 0
versions = ["2012.17",
"2014.2",
"2014.4",
"2014.50",
"2014.51",
"2014.59"]
variants = [ 'platform-linux' ]
help = 'google-chrome http://download.autodesk.com/global/docs/maya2014/en_us/index.html'
def commands():
env.MAYA_VERSION_NUM = version.major
env.CMAKE_MODULE_PATH.append('{root}/cmake')
if machine.platform == 'linux':
env.MAYA_LOCATION = '/usr/autodesk/maya{version:#0.#01}-x64'
elif machine.platform == 'darwin':
env.MAYA_LOCATION = '/Applications/Autodesk/maya{version:#0.#01}/Maya.app/Contents'
elif machine.platform == 'windows':
env.MAYA_LOCATION = 'C:/Autodesk/maya{version.major}-x64'
env.PATH.prepend('$MAYA_LOCATION/bin')
env.MAYA_DEBUG_ENABLE_CRASH_REPORTING = 1
tools = ['maya',
'mayapy']
with overrides():
version = '2012|2013'
requires = ['python-2.6']
# local override for 2012/2013:
# moving forward we will only support linux
variants = [
[ 'platform-linux' ],
[ 'platform-darwin' ]]
with overrides():
version = '2014'
requires = ['python-2.7'] |
One feature that I'd really like to see in rez is the ability to manage external applications using a single multi-version package file.
A quick clarification of terms:
I've added this multi-version package feature in my own fork and used it for awhile, and it makes managing applications like maya and nuke much easier. Previously I had a directory structure like this:
(Note that all of those variant sub-directories are empty, they exist because rez errors if they don't. Also, I stopped using the
extsymlink +'!ROOT!'because I found it hurt more than helped)Now, with my fork, I have a single file called
maya.yamlthat looks like this:The
---separates yaml sub-documents. The first sub-doc provides the global values that apply to all versions, and the remaining sub-docs provide version-specific overrides.On the one hand, I know that package files are meant to be immutable once released, and while I try to stick to that rule for built packages, for external packages I find it very difficult. Adjustments sometimes need to be made that affect the package.yaml of every version of a package, or, even worse in terms of automation, most of them but not all. This single file gives a comprehensible birds-eye-view of the differences between versions. I put these external package definitions under version control and manage new releases and modifications by editing and committing these files.
Another perk is that when editing many rez package files it is much easier to keep track of what package you're editing, since they're not all named package.yaml.
One issue that I still need to address is time-stamping, as I'm still a novice with rez's timestamp mechanics. I'm hoping that these can be handled either automatically in an external side-car file (e.g. .maya-release.yaml) or by manually, by editing a
timestampsmetadata field in the package file. I'm open to suggestions.To me this is a killer feature and I'd like for it to be included in rez, but I'd like to hear what people think.
The text was updated successfully, but these errors were encountered: