Previous topic

oyProjectManager.core.models.VersionStatusComparator

Next topic

oyProjectManager.db

This Page

oyProjectManager.core.models.VersionType

Inheritance diagram of oyProjectManager.core.models.VersionType

class oyProjectManager.core.models.VersionType(name, code, path, filename, output_path, environments, type_for, extra_folders=None)[source]

Bases: sqlalchemy.ext.declarative.Base

A template for Version class.

A VersionType is basically a template object for the Version instances. It gives the information about the filename template, path template and output path template for the Version class. Then the Version class renders this Jinja2 templates and places itself (or the produced files) in to the appropriate folders in the Repository.

All the template variables ( filename, path, output_path) can use the following variables in their template codes.

Variable Name Variable Source Description
project version.version_of.project The project that the Version belongs to
sequence version.version_of.sequence Only available for Shot versions
version version The version itself
type version.type The VersionType instance attached to the this Version

In oyProjectManager, generally you don’t need to create VersionType instances by hand. Instead, add all the version types you need to your config.py file and the Project instance will create all the necessary VersionTypes from this config.py configuration file. For more information about the the config.py please see the documentation of config.py.

For previously created projects, where a new type is needed to be added you can still create a new VersionType instance and save it to the Projects’ database.

Parameters:
  • name (str) – The name of this template. The name is not formatted in anyway. It can not be skipped or it can not be None or it can not be an empty string. The name attribute should be unique. Be careful that even specifying a non unique name VersionType instance will not raise an error until save() is called.
  • code (str) –

    The code is a shorthand form of the name. For example, if the name is “Animation” than the code can be “ANIM” or “Anim” or “anim”. Because the code is generally used in filename, path or output_path templates it is going to be a part of the filename or path, so be careful about what you give as a code. The code attribute should be unique. Be careful that even specifying a non unique code VersionType instance will not raise an error until save() is called. For formatting, these rules are current:

    • no white space characters are allowed
    • can not start with a number
    • can not start or end with an underscore character
    • both lowercase or uppercase letters are allowed

    A good code is the short form of the name attribute. Examples:

    Name Code
    Animation Anim or ANIM
    Composition Comp or COMP
    Match Move MM
    Camera Track Track or TACK
    Model Model or MODEL
    Rig Rig or RIG
    Scene Assembly Asmbly or ASMBLY
    Lighting Lighting or LIGHTING
    Camera Cam or CAM
  • filename

    The filename template. It is a single line Jinja2 template showing the filename of the Version which is using this VersionType. Look for the above table for possible variables those can be used in the template code.

    For an example the following is a nice example for Asset version filename:

    {{version.base_name}}_{{version.take_name}}_{{type.code}}_\
      v{{'%03d'|format(version.version_number)}}_\
      {{version.created_by.initials}}

    Which will render something like that:

    Car_Main_Model_v001_oy
    

    Now all the versions for the same asset will have a consistent name.

    When the filename argument is skipped or is an empty string is given a TypeError will be raised to prevent creation of files with no names.

  • path (str) –

    The path template. It is a single line Jinja2 template showing the absolute path of this Version instance. Look for the above table for possible variables those can be used in the template code.

    For an example the following is a nice template for a Shot version:

    {{project.full_path}}/Sequences/{{sequence.code}}/Shots/\
      {{version.base_name}}/{{type.code}}
    

    This will place a Shot Version whose base_name is SH001 and let say that the type is Animation (where the code is ANIM) to a path like:

    M:/JOBs/PROJ1/Sequences/SEQ1/Shots/SH001/ANIM

    All the animation files realted to this shot will be saved inside that folder.

  • output_path (str) –

    It is a single line Jinja2 template which shows where to place the outputs of this kind of Versions. An output is simply anything that is rendered out from the source file, it can be the renders or playblast/flipbook outputs for Maya, Nuke or Houdini and can be different file type versions (tga, jpg, etc.) for Photoshop files.

    Generally it is a good idea to store the output right beside the source file. So for a Shot the following is a good example:

    {{version.path}}/Outputs
    

    Which will render as:

    M:/JOBs/PROJ1/Sequences/SEQ1/Shots/SH001/ANIM/Outputs
  • extra_folders (str) –

    It is a list of single line Jinja2 template codes which are showing the extra folders those need to be created. It is generally created in the Project creation phase.

    The following is an extra folder hierarchy created for the FX version type:

    {{version.path}}/cache
    
  • environments (list of strings) –

    A list of environments that this VersionType is valid for. The idea behind is to limit the possible list of types for the program that the user is working on. So let say it may not possible to create a camera track in Photoshop then what one can do is to add a Camera Track type but exclude the Photoshop from the list of environments that this type is valid for.

    The given value should be a list of environment names, be careful about not to pass just a string for the environments list, python will convert the string to a list by putting all the letters in separate elements in the list. And probably this is not something one wants.

  • type_for – An enum value specifying what this VersionType instance is for, is it for an “Asset” or for an “Shot”. The two acceptable values are “Asset” or “Shot”. Any other value will raise an IntegrityError. It can not be skipped.
__init__(name, code, path, filename, output_path, environments, type_for, extra_folders=None)[source]

Methods

__init__(name, code, path, filename, ...[, ...])
query()
save() Saves the current VersionType to the database

Attributes

code
environments A descriptor that presents a read/write view of an object attribute.
extra_folders A string containing the extra folder names those needs to be
filename The filename template for this type of version instances.
id
metadata A collection of Table objects and their associated schema constructs.
name
output_path The output path template for this Type of Version instances.
path The path template for this Type of Version instance.
type_for An enum attribute holds what is this VersionType created for, a Shot
filename

The filename template for this type of version instances.

You can freely change the filename template attribute after creating Versions of this type. Any Version which is created prior to this change will not be effected. But be careful about the older and newer Versions of the same Asset or Shot may placed to different folders according to your new template.

The template should not include a dot (”.”) sign before the extension, it is handled by the Version instance.

path

The path template for this Type of Version instance.

You can freely change the path template attribute after creating Versions of this type. Any Version which is created prior to this change will not be effected. But be careful about the older and newer Versions of the same Asset or Shot may placed to different folders according to your new template.

The path template should be an relative one to the server_path, so don’t forget to place {{project.code}} at the beginning of your template if you are storing all your asset and shots inside the project directory.

If you want to store your assets in one place and use them in several projects, you can do it by starting the path of the VersionType with something like that:

"Assets/{{version.base_name}}/{{type.code}}"

and if your repository path is “/mnt/M/JOBs” then your assets will be stored in:

"/mnt/M/JOBs/Assets"
output_path

The output path template for this Type of Version instances.

To place your output path right beside the original version file you can set the output_path to:

"{{version.path}}/Outputs/{{version.take_name}}"
extra_folders

A string containing the extra folder names those needs to be created

save()[source]

Saves the current VersionType to the database

type_for[source]

An enum attribute holds what is this VersionType created for, a Shot or an Asset.