explanation/example of variants ?

[dougepps]

i'm sure this is basic, but I'm not easily grokking it.

I'm looking to make a cross-platform "maya" package, so each platform needs a different path to the maya install dir.

I feel like: variants = [ ["platform-osx", "platform-win", "platform-linux"] ]

or something is along the right lines, but with that I get: maya-2014 /Users/DougEpps/packages/maya/2014/platform-osx (NOT FOUND, local)

or is there a way in the commands() to find out the context (arch, platform, etc) I'm running under and put the config in there ?

if rez.os == "osx": path = "/Applications/Autodesk" elif rez.os == "win": path = "c:/Program Files"

Seems like this is definitely something considered already, I'm just not seeing how to deal with it.

Also looking for a little help with what rez-build and/or rez-install/release do.

Fired up for rez, just need to understand it a little better !

[nerdvegas]

Hey Doug,

It will probably help to take a look at the (old) user manual: http://nerdvegas.github.io/rez. Some of the finer details are old (the commanline tools have changed, and the "wrapper" chapter is not relevant anymore) but a lot of that doc still fairly accurately describes what rez does, what variants are and so on. I'm in the process of writing the new docs, but it's a lot of work.

To answer your question directly:

So yes, variants are very often used for cross platform packages, and especially if you are building your package, this is the right way to go. You have the syntax a bit wrong though, this is more what you're after:

variants = [ ["platform-linux"], ["platform-osx"], ["platform-windows"] ]

This describes 3 variants in a package. Each variant is a list of package requirements, that get added to the main "requires" list. Think of variants as different flavors of the same package. "platform" is actually a rez package, and "linux", "osx" and "windows" are the version numbers(!). It's done this way because it gives us a nice property - it makes it impossible to mix together packages for different platforms, because the dependency resolving algorithm makes that impossible - two different versions of a package cannot be present in the same environment at once.

For each variant, a matching subdirectory in your package install is expected. So in this case, these directories are expected:

~/packages/maya/2014/platform-linux ~/packages/maya/2014/platform-osx ~/packages/maya/2014/platform-windows

If you are building/installing a package (rez-build, rez-release) then these directories are created for you, and the installation process installs into them. At runtime, when you use rez-env, the correct variant is chosen automagically. So lets say my maya package had the following commands:

def commands(): env.PATH.append("{root}/bin")

"{root}" is a special variable that expands out to the installed variant location. So, assuming I created this env:

]$ rez-env maya platform-linux

..the package's commands would translate into this bash code:

export PATH=$PATH:~/packages/maya/2014/platform-linux/bin

..and the linux variant of your maya package would have its binaries correctly exposed on PATH.

Please be aware that there are also a set of "implicit" packages (configurable) that are always added to the resolve when you use rez-env. You can check what these are with the "rez-config" tool, which prints out rez config settings (taking a look at the source file rezconfig.py is also recommended, it contains all the defaults, and has comments explaining every setting). Typically the platform is included in this implicit list, so if you were on linux, you might find that trying to do "rez-env maya platform-osx" will fail with a conflict. That's because the implicit platform-linux dependency would be clashing with your platform-osx request.

Hth, A

On Thu, Jan 21, 2016 at 10:51 AM, Doug Epps notifications@github.com wrote:

i'm sure this is basic, but I'm not easily grokking it.

I'm looking to make a cross-platform "maya" package, so each platform needs a different path to the maya install dir.

I feel like: variants = [ ["platform-osx", "platform-win", "platform-linux"] ]

or something is along the right lines, but with that I get: maya-2014 /Users/DougEpps/packages/maya/2014/platform-osx (NOT FOUND, local)

or is there a way in the commands() to find out the context (arch, platform, etc) I'm running under and put the config in there ?

if rez.os == "osx": path = "/Applications/Autodesk" elif rez.os == "win": path = "c:/Program Files"

Seems like this is definitely something considered already, I'm just not seeing how to deal with it.

Also looking for a little help with what rez-build and/or rez-install/release do.

Fired up for rez, just need to understand it a little better !

— Reply to this email directly or view it on GitHub https://github.com/nerdvegas/rez/issues/291.

[dougepps]

This kind of makes sense to me.

But I’m fuzzy on how to do the basic “this is how maya should be run cross-platform”.

I’m imagining that there will be a lot of “shared code” between a package’s setups among the platforms, so I’d like to have the bulk of that be in my “generic” package.py ( ~/packages/maya/2014/package.py) and then have just the info needed for different platforms in the os specific location.

Is that possible ?

I.e ~/packages/maya/2014/package.py sets a python variable mayaRoot and then ~/packages/maya/2014/package.py uses that to construct paths.

In a similar vein, your example {root}/bin pre-supposes that all the binaries are in the ~/packages/maya/2014 somewhere, whereas I’d like to just add a directory to the PATH.

Also, I just put a print statement in the commands() for ~/packages/maya/2014/package.py and ~/packages/maya/2014/platform-osx/package.py and I’m only seeing the “generic” one. (even though I have to have the platform-osx in there or it complains, so it’s seeing it somehow).

thanks again. Once I crack this, I think I’m in-love.

On Jan 21, 2016, at 11:57 AM, allan johns notifications@github.com wrote:

Hey Doug,

It will probably help to take a look at the (old) user manual: http://nerdvegas.github.io/rez. Some of the finer details are old (the commanline tools have changed, and the "wrapper" chapter is not relevant anymore) but a lot of that doc still fairly accurately describes what rez does, what variants are and so on. I'm in the process of writing the new docs, but it's a lot of work.

To answer your question directly:

So yes, variants are very often used for cross platform packages, and especially if you are building your package, this is the right way to go. You have the syntax a bit wrong though, this is more what you're after:

variants = [ ["platform-linux"], ["platform-osx"], ["platform-windows"] ]

This describes 3 variants in a package. Each variant is a list of package requirements, that get added to the main "requires" list. Think of variants as different flavors of the same package. "platform" is actually a rez package, and "linux", "osx" and "windows" are the version numbers(!). It's done this way because it gives us a nice property - it makes it impossible to mix together packages for different platforms, because the dependency resolving algorithm makes that impossible - two different versions of a package cannot be present in the same environment at once.

For each variant, a matching subdirectory in your package install is expected. So in this case, these directories are expected:

~/packages/maya/2014/platform-linux ~/packages/maya/2014/platform-osx ~/packages/maya/2014/platform-windows

If you are building/installing a package (rez-build, rez-release) then these directories are created for you, and the installation process installs into them. At runtime, when you use rez-env, the correct variant is chosen automagically. So lets say my maya package had the following commands:

def commands(): env.PATH.append("{root}/bin")

"{root}" is a special variable that expands out to the installed variant location. So, assuming I created this env:

]$ rez-env maya platform-linux

..the package's commands would translate into this bash code:

export PATH=$PATH:~/packages/maya/2014/platform-linux/bin

..and the linux variant of your maya package would have its binaries correctly exposed on PATH.

Please be aware that there are also a set of "implicit" packages (configurable) that are always added to the resolve when you use rez-env. You can check what these are with the "rez-config" tool, which prints out rez config settings (taking a look at the source file rezconfig.py is also recommended, it contains all the defaults, and has comments explaining every setting). Typically the platform is included in this implicit list, so if you were on linux, you might find that trying to do "rez-env maya platform-osx" will fail with a conflict. That's because the implicit platform-linux dependency would be clashing with your platform-osx request.

Hth, A

On Thu, Jan 21, 2016 at 10:51 AM, Doug Epps notifications@github.com wrote:

i'm sure this is basic, but I'm not easily grokking it.

I'm looking to make a cross-platform "maya" package, so each platform needs a different path to the maya install dir.

I feel like: variants = [ ["platform-osx", "platform-win", "platform-linux"] ]

or something is along the right lines, but with that I get: maya-2014 /Users/DougEpps/packages/maya/2014/platform-osx (NOT FOUND, local)

or is there a way in the commands() to find out the context (arch, platform, etc) I'm running under and put the config in there ?

if rez.os == "osx": path = "/Applications/Autodesk" elif rez.os == "win": path = "c:/Program Files"

Seems like this is definitely something considered already, I'm just not seeing how to deal with it.

Also looking for a little help with what rez-build and/or rez-install/release do.

Fired up for rez, just need to understand it a little better !

— Reply to this email directly or view it on GitHub https://github.com/nerdvegas/rez/issues/291.

— Reply to this email directly or view it on GitHub https://github.com/nerdvegas/rez/issues/291#issuecomment-173690884.

[nerdvegas]

For a platform-dependent package such as maya, you typically want your entire payload to be specifically for that platform - bins, libs etc. Even for an internally developed package, you typically don't want part of that to be platform-agnostic and part platform-dependent. In cases where the code is the same across platforms - for eg perhaps a python-based executable is the same on linux and windows - the build process will just install duplicates to each platform-specific variant, but that in itself doesn't cause any problems.

It's much more common to have a case where a package has a 'common' part, and an application-specific part; consider a crowd system that has a common library, and integration for both Maya and Houdini. Currently the best way to deal with that is to split your project into several parts - common, maya and houdini - and just have the maya and houdini packages depend on the common package.

"""Also, I just put a print statement in the commands() for ~/packages/maya/2014/package.py and ~/packages/maya/2014/platform-osx/package.py and I’m only seeing the “generic” one."""

~/packages/maya/2014/platform-osx/package.py is not a valid location for a package. The package.py is the package definition file. It is always located at the base of the package install, regardless of the variants the package has. Packages are always located at ~/packages/PKG_NAME/VERSION/package.py.

It might help to run "rez-build -i" in this hello_world example: https://github.com/nerdvegas/rez/tree/master/repository/hello_world_py/1.0.0. You can play around with the package.py there and see how adding variants affects the layout of the installed package. The user manual I gave a link to earlier also goes into detail on how a package is laid out on disk.

"""In a similar vein, your example {root}/bin pre-supposes that all the binaries are in the ~/packages/maya/2014 somewhere, whereas I’d like to just add a directory to the PATH."""

You can append/prepend/set whatever you like to PATH. Example:

def commands(): import platform path="/svr/maya/{this.version}/%s/bin" % platform.uname[0] env.PATH.append(path)

Rez also provides a 'system' object for you:

def commands(): path="/svr/maya/{this.version}/{system.platform}/bin" env.PATH.append(path)

However, if you do this, and you don't use variants, you are hiding your package's platform dependency from rez. That isn't wrong per se, just something to know. Of course, you could do both - have platform-based variants, and append absolute paths outside of your payload area to PATH as shown above.

"""I.e ~/packages/maya/2014/package.py sets a python variable mayaRoot and then ~/packages/maya/2014/package.py uses that to construct paths."""

package.py files are not to be treated like normal python files. They do not import each other or anything like that. They are standalone package definition files - in fact there is still support for package.yaml (yaml is the old format and no longer recommended to use).

Hth A

On Thu, Jan 21, 2016 at 12:26 PM, Doug Epps notifications@github.com wrote:

This kind of makes sense to me.

But I’m fuzzy on how to do the basic “this is how maya should be run cross-platform”.

I’m imagining that there will be a lot of “shared code” between a package’s setups among the platforms, so I’d like to have the bulk of that be in my “generic” package.py ( ~/packages/maya/2014/package.py) and then have just the info needed for different platforms in the os specific location.

Is that possible ?

I.e ~/packages/maya/2014/package.py sets a python variable mayaRoot and then ~/packages/maya/2014/package.py uses that to construct paths.

In a similar vein, your example {root}/bin pre-supposes that all the binaries are in the ~/packages/maya/2014 somewhere, whereas I’d like to just add a directory to the PATH.

Also, I just put a print statement in the commands() for ~/packages/maya/2014/package.py and ~/packages/maya/2014/platform-osx/package.py and I’m only seeing the “generic” one. (even though I have to have the platform-osx in there or it complains, so it’s seeing it somehow).

thanks again. Once I crack this, I think I’m in-love.

On Jan 21, 2016, at 11:57 AM, allan johns notifications@github.com wrote:

Hey Doug,

It will probably help to take a look at the (old) user manual: http://nerdvegas.github.io/rez. Some of the finer details are old (the commanline tools have changed, and the "wrapper" chapter is not relevant anymore) but a lot of that doc still fairly accurately describes what rez does, what variants are and so on. I'm in the process of writing the new docs, but it's a lot of work.

To answer your question directly:

So yes, variants are very often used for cross platform packages, and especially if you are building your package, this is the right way to go. You have the syntax a bit wrong though, this is more what you're after:

variants = [ ["platform-linux"], ["platform-osx"], ["platform-windows"] ]

This describes 3 variants in a package. Each variant is a list of package requirements, that get added to the main "requires" list. Think of variants as different flavors of the same package. "platform" is actually a rez package, and "linux", "osx" and "windows" are the version numbers(!). It's done this way because it gives us a nice property - it makes it impossible to mix together packages for different platforms, because the dependency resolving algorithm makes that impossible - two different versions of a package cannot be present in the same environment at once.

For each variant, a matching subdirectory in your package install is expected. So in this case, these directories are expected:

~/packages/maya/2014/platform-linux ~/packages/maya/2014/platform-osx ~/packages/maya/2014/platform-windows

If you are building/installing a package (rez-build, rez-release) then these directories are created for you, and the installation process installs into them. At runtime, when you use rez-env, the correct variant is chosen automagically. So lets say my maya package had the following commands:

def commands(): env.PATH.append("{root}/bin")

"{root}" is a special variable that expands out to the installed variant location. So, assuming I created this env:

]$ rez-env maya platform-linux

..the package's commands would translate into this bash code:

export PATH=$PATH:~/packages/maya/2014/platform-linux/bin

..and the linux variant of your maya package would have its binaries correctly exposed on PATH.

Please be aware that there are also a set of "implicit" packages (configurable) that are always added to the resolve when you use rez-env. You can check what these are with the "rez-config" tool, which prints out rez config settings (taking a look at the source file rezconfig.py is also recommended, it contains all the defaults, and has comments explaining every setting). Typically the platform is included in this implicit list, so if you were on linux, you might find that trying to do "rez-env maya platform-osx" will fail with a conflict. That's because the implicit platform-linux dependency would be clashing with your platform-osx request.

Hth, A

On Thu, Jan 21, 2016 at 10:51 AM, Doug Epps notifications@github.com wrote:

i'm sure this is basic, but I'm not easily grokking it.

I'm looking to make a cross-platform "maya" package, so each platform needs a different path to the maya install dir.

I feel like: variants = [ ["platform-osx", "platform-win", "platform-linux"] ]

or something is along the right lines, but with that I get: maya-2014 /Users/DougEpps/packages/maya/2014/platform-osx (NOT FOUND, local)

or is there a way in the commands() to find out the context (arch, platform, etc) I'm running under and put the config in there ?

if rez.os == "osx": path = "/Applications/Autodesk" elif rez.os == "win": path = "c:/Program Files"

Seems like this is definitely something considered already, I'm just not seeing how to deal with it.

Also looking for a little help with what rez-build and/or rez-install/release do.

Fired up for rez, just need to understand it a little better !

— Reply to this email directly or view it on GitHub https://github.com/nerdvegas/rez/issues/291.

— Reply to this email directly or view it on GitHub < https://github.com/nerdvegas/rez/issues/291#issuecomment-173690884>.

— Reply to this email directly or view it on GitHub https://github.com/nerdvegas/rez/issues/291#issuecomment-173698033.

[dougepps]

ok.

So, generically,

I edit

/maya/2014/package.py to set things, then run: res-build -i which looks in there for variants and makes entries in ~/packages/ for me … yes ? (I was editing by hand). How then do I set paths that are platform specific ? with variables ala platform.uname like you did ? Does that imply I have to res-build on each target architecture ? (which for compiled stuff makes sense, but not for something pre-built like maya). Thanks for talking me through this. -doug If we can hack up an example for maya, (windows, linux, OS X,) maybe it would be useful to put in the repo ? > On Jan 21, 2016, at 1:46 PM, allan johns notifications@github.com wrote: > > For a platform-dependent package such as maya, you typically want your > entire payload to be specifically for that platform - bins, libs etc. Even > for an internally developed package, you typically don't want part of that > to be platform-agnostic and part platform-dependent. In cases where the > code is the same across platforms - for eg perhaps a python-based > executable is the same on linux and windows - the build process will just > install duplicates to each platform-specific variant, but that in itself > doesn't cause any problems. > > It's much more common to have a case where a package has a 'common' part, > and an application-specific part; consider a crowd system that has a common > library, and integration for both Maya and Houdini. Currently the best way > to deal with that is to split your project into several parts - common, > maya and houdini - and just have the maya and houdini packages depend on > the common package. > > """Also, I just put a print statement in the commands() for > ~/packages/maya/2014/package.py and > ~/packages/maya/2014/platform-osx/package.py and I’m only seeing the > “generic” one.""" > > ~/packages/maya/2014/platform-osx/package.py is not a valid location for a > package. The package.py is the package definition file. It is always > located at the base of the package install, regardless of the variants the > package has. Packages are always located at > ~/packages/PKG_NAME/VERSION/package.py. > > It might help to run "rez-build -i" in this hello_world example: > https://github.com/nerdvegas/rez/tree/master/repository/hello_world_py/1.0.0. > You can play around with the package.py there and see how adding variants > affects the layout of the installed package. The user manual I gave a link > to earlier also goes into detail on how a package is laid out on disk. > > """In a similar vein, your example {root}/bin pre-supposes that all the > binaries are in the ~/packages/maya/2014 somewhere, whereas I’d like to > just add a directory to the PATH.""" > > You can append/prepend/set whatever you like to PATH. Example: > > def commands(): > import platform > path="/svr/maya/{this.version}/%s/bin" % platform.uname[0] > env.PATH.append(path) > > Rez also provides a 'system' object for you: > > def commands(): > path="/svr/maya/{this.version}/{system.platform}/bin" > env.PATH.append(path) > > However, if you do this, and you don't use variants, you are hiding your > package's platform dependency from rez. That isn't wrong per se, just > something to know. Of course, you could do both - have platform-based > variants, and append absolute paths outside of your payload area to PATH as > shown above. > > """I.e ~/packages/maya/2014/package.py sets a python variable mayaRoot and > then ~/packages/maya/2014/package.py uses that to construct paths.""" > > package.py files are not to be treated like normal python files. They do > not import each other or anything like that. They are standalone package > definition files - in fact there is still support for package.yaml (yaml is > the old format and no longer recommended to use). > > Hth > A > > On Thu, Jan 21, 2016 at 12:26 PM, Doug Epps notifications@github.com > wrote: > > > This kind of makes sense to me. > > > > But I’m fuzzy on how to do the basic “this is how maya should be run > > cross-platform”. > > > > I’m imagining that there will be a lot of “shared code” between a > > package’s setups among the platforms, so I’d like to have the bulk of that > > be in my “generic” package.py ( ~/packages/maya/2014/package.py) and then > > have just the info needed for different platforms in the os specific > > location. > > > > Is that possible ? > > > > I.e ~/packages/maya/2014/package.py sets a python variable mayaRoot and > > then ~/packages/maya/2014/package.py uses that to construct paths. > > > > In a similar vein, your example {root}/bin pre-supposes that all the > > binaries are in the ~/packages/maya/2014 somewhere, whereas I’d like to > > just add a directory to the PATH. > > > > Also, I just put a print statement in the commands() for > > ~/packages/maya/2014/package.py and > > ~/packages/maya/2014/platform-osx/package.py and I’m only seeing the > > “generic” one. > > (even though I have to have the platform-osx in there or it complains, so > > it’s seeing it somehow). > > > > thanks again. Once I crack this, I think I’m in-love. > > > > > On Jan 21, 2016, at 11:57 AM, allan johns notifications@github.com > > > wrote: > > > > > > Hey Doug, > > > > > > It will probably help to take a look at the (old) user manual: > > > http://nerdvegas.github.io/rez. Some of the finer details are old (the > > > commanline tools have changed, and the "wrapper" chapter is not relevant > > > anymore) but a lot of that doc still fairly accurately describes what rez > > > does, what variants are and so on. I'm in the process of writing the new > > > docs, but it's a lot of work. > > > > > > To answer your question directly: > > > > > > So yes, variants are very often used for cross platform packages, and > > > especially if you are building your package, this is the right way to go. > > > You have the syntax a bit wrong though, this is more what you're after: > > > > > > variants = [ > > > ["platform-linux"], > > > ["platform-osx"], > > > ["platform-windows"] > > > ] > > > > > > This describes 3 variants in a package. Each variant is a list of package > > > requirements, that get _added_ to the main "requires" list. Think of > > > variants as different flavors of the same package. "platform" is > > > actually a > > > rez package, and "linux", "osx" and "windows" are the version numbers(!). > > > It's done this way because it gives us a nice property - it makes it > > > impossible to mix together packages for different platforms, because the > > > dependency resolving algorithm makes that impossible - two different > > > versions of a package cannot be present in the same environment at once. > > > > > > For each variant, a matching subdirectory in your package install is > > > expected. So in this case, these directories are expected: > > > > > > ~/packages/maya/2014/platform-linux > > > ~/packages/maya/2014/platform-osx > > > ~/packages/maya/2014/platform-windows > > > > > > If you are building/installing a package (rez-build, rez-release) then > > > these directories are created for you, and the installation process > > > installs into them. At runtime, when you use rez-env, the correct variant > > > is chosen automagically. So lets say my maya package had the following > > > commands: > > > > > > def commands(): > > > env.PATH.append("{root}/bin") > > > > > > "{root}" is a special variable that expands out to the installed variant > > > location. So, assuming I created this env: > > > > > > ]$ rez-env maya platform-linux > > > > > > ..the package's commands would translate into this bash code: > > > > > > export PATH=$PATH:~/packages/maya/2014/platform-linux/bin > > > > > > ..and the linux variant of your maya package would have its binaries > > > correctly exposed on PATH. > > > > > > Please be aware that there are also a set of "implicit" packages > > > (configurable) that are always added to the resolve when you use rez-env. > > > You can check what these are with the "rez-config" tool, which prints out > > > rez config settings (taking a look at the source file rezconfig.py is > > > also > > > recommended, it contains all the defaults, and has comments explaining > > > every setting). Typically the platform is included in this implicit list, > > > so if you were on linux, you might find that trying to do "rez-env maya > > > platform-osx" will fail with a conflict. That's because the implicit > > > platform-linux dependency would be clashing with your platform-osx > > > request. > > > > > > Hth, > > > A > > > > > > On Thu, Jan 21, 2016 at 10:51 AM, Doug Epps notifications@github.com > > > wrote: > > > > > > > i'm sure this is basic, but I'm not easily grokking it. > > > > > > > > I'm looking to make a cross-platform "maya" package, so each platform > > > > needs a different path to the maya install dir. > > > > > > > > I feel like: > > > > variants = [ > > > > ["platform-osx", "platform-win", "platform-linux"] > > > > ] > > > > > > > > or something is along the right lines, but with that I get: > > > > maya-2014 /Users/DougEpps/packages/maya/2014/platform-osx (NOT FOUND, > > > > local) > > > > > > > > or is there a way in the commands() to find out the context (arch, > > > > platform, etc) I'm running under and put the config in there ? > > > > > > > > if rez.os == "osx": > > > > path = "/Applications/Autodesk" > > > > elif rez.os == "win": > > > > path = "c:/Program Files" > > > > > > > > Seems like this is definitely something considered already, I'm just > > > > not > > > > seeing how to deal with it. > > > > > > > > Also looking for a little help with what rez-build and/or > > > > rez-install/release do. > > > > > > > > Fired up for rez, just need to understand it a little better ! > > > > > > > > — > > > > Reply to this email directly or view it on GitHub > > > > https://github.com/nerdvegas/rez/issues/291. > > > > > > > > — > > > > Reply to this email directly or view it on GitHub < > > > > https://github.com/nerdvegas/rez/issues/291#issuecomment-173690884>. > > > > — > > Reply to this email directly or view it on GitHub > > https://github.com/nerdvegas/rez/issues/291#issuecomment-173698033. > > > > — > > Reply to this email directly or view it on GitHub https://github.com/nerdvegas/rez/issues/291#issuecomment-173719335.

[nerdvegas]

Below.

On Thu, Jan 21, 2016 at 2:03 PM, Doug Epps notifications@github.com wrote:

ok.

So, generically,

I edit

/maya/2014/package.py to set things, then run: res-build -i which looks in there for variants and makes entries in ~/packages/ for me … yes ?

Yes. Rez builds the package and, if -i is present, installs it into the relevant location under ~/packages.

(I was editing by hand).

You can do that too. If a package is properly formed - ie the correct directories present and package.py in the right place - rez will consume it as a package.

How then do I set paths that are platform specific ? with variables ala platform.uname like you did ?

You can do that yes. Or, if your package contains platform-dependent code as a variant installation, you'd probably make use of "{root}" also.

Does that imply I have to res-build on each target architecture ?

Yes it does. There is currently not a build process for remote builds unfortunately. But instead you could ssh onto the correct platform host, then use the rez-build -v flag to selectively build a particular variant.

(which for compiled stuff makes sense, but not for something pre-built like maya).

In rez packages you can override settings. So if you wanted to use rez-build to install, but you don't actually need to build anything, you could override the "implicit packages" setting and set it to nothing. That way the build will happily iterate over every variant, even though you aren't actually on that platform. I haven't tested this but it should work. Here's what you'll want to add:

with scope('config') as config: config.implicit_packages = []

But before doing that, I would just get everything set up with a single variant for the current platform and see that that's working first.

Thanks for talking me through this.

-doug

If we can hack up an example for maya, (windows, linux, OS X,) maybe it would be useful to put in the repo ?

We could put an example like this in the repo yes, could be useful for prebuilt installations such as maya. However there are studios out there that run the entire build through rez, even for large packages such as maya and houdini (my own studio included). So if this kind of package were added to the repo I would name it something like "maya_prebuilt".

A

On Jan 21, 2016, at 1:46 PM, allan johns notifications@github.com wrote:

For a platform-dependent package such as maya, you typically want your entire payload to be specifically for that platform - bins, libs etc. Even for an internally developed package, you typically don't want part of that to be platform-agnostic and part platform-dependent. In cases where the code is the same across platforms - for eg perhaps a python-based executable is the same on linux and windows - the build process will just install duplicates to each platform-specific variant, but that in itself doesn't cause any problems.

It's much more common to have a case where a package has a 'common' part, and an application-specific part; consider a crowd system that has a common library, and integration for both Maya and Houdini. Currently the best way to deal with that is to split your project into several parts - common, maya and houdini - and just have the maya and houdini packages depend on the common package.

"""Also, I just put a print statement in the commands() for ~/packages/maya/2014/package.py and ~/packages/maya/2014/platform-osx/package.py and I’m only seeing the “generic” one."""

~/packages/maya/2014/platform-osx/package.py is not a valid location for a package. The package.py is the package definition file. It is always located at the base of the package install, regardless of the variants the package has. Packages are always located at ~/packages/PKG_NAME/VERSION/package.py.

It might help to run "rez-build -i" in this hello_world example:

https://github.com/nerdvegas/rez/tree/master/repository/hello_world_py/1.0.0 . You can play around with the package.py there and see how adding variants affects the layout of the installed package. The user manual I gave a link to earlier also goes into detail on how a package is laid out on disk.

"""In a similar vein, your example {root}/bin pre-supposes that all the binaries are in the ~/packages/maya/2014 somewhere, whereas I’d like to just add a directory to the PATH."""

You can append/prepend/set whatever you like to PATH. Example:

def commands(): import platform path="/svr/maya/{this.version}/%s/bin" % platform.uname[0] env.PATH.append(path)

Rez also provides a 'system' object for you:

def commands(): path="/svr/maya/{this.version}/{system.platform}/bin" env.PATH.append(path)

However, if you do this, and you don't use variants, you are hiding your package's platform dependency from rez. That isn't wrong per se, just something to know. Of course, you could do both - have platform-based variants, and append absolute paths outside of your payload area to PATH as shown above.

"""I.e ~/packages/maya/2014/package.py sets a python variable mayaRoot and then ~/packages/maya/2014/package.py uses that to construct paths."""

package.py files are not to be treated like normal python files. They do not import each other or anything like that. They are standalone package definition files - in fact there is still support for package.yaml (yaml is the old format and no longer recommended to use).

Hth A

On Thu, Jan 21, 2016 at 12:26 PM, Doug Epps notifications@github.com wrote:

This kind of makes sense to me.

But I’m fuzzy on how to do the basic “this is how maya should be run cross-platform”.

I’m imagining that there will be a lot of “shared code” between a package’s setups among the platforms, so I’d like to have the bulk of that be in my “generic” package.py ( ~/packages/maya/2014/package.py) and then have just the info needed for different platforms in the os specific location.

Is that possible ?

I.e ~/packages/maya/2014/package.py sets a python variable mayaRoot and then ~/packages/maya/2014/package.py uses that to construct paths.

In a similar vein, your example {root}/bin pre-supposes that all the binaries are in the ~/packages/maya/2014 somewhere, whereas I’d like to just add a directory to the PATH.

Also, I just put a print statement in the commands() for ~/packages/maya/2014/package.py and ~/packages/maya/2014/platform-osx/package.py and I’m only seeing the “generic” one. (even though I have to have the platform-osx in there or it complains, so it’s seeing it somehow).

thanks again. Once I crack this, I think I’m in-love.

On Jan 21, 2016, at 11:57 AM, allan johns notifications@github.com wrote:

Hey Doug,

It will probably help to take a look at the (old) user manual: http://nerdvegas.github.io/rez. Some of the finer details are old (the commanline tools have changed, and the "wrapper" chapter is not relevant anymore) but a lot of that doc still fairly accurately describes what rez does, what variants are and so on. I'm in the process of writing the new docs, but it's a lot of work.

To answer your question directly:

So yes, variants are very often used for cross platform packages, and especially if you are building your package, this is the right way to go. You have the syntax a bit wrong though, this is more what you're after:

variants = [ ["platform-linux"], ["platform-osx"], ["platform-windows"] ]

This describes 3 variants in a package. Each variant is a list of package requirements, that get added to the main "requires" list. Think of variants as different flavors of the same package. "platform" is actually a rez package, and "linux", "osx" and "windows" are the version numbers(!). It's done this way because it gives us a nice property - it makes it impossible to mix together packages for different platforms, because the dependency resolving algorithm makes that impossible - two different versions of a package cannot be present in the same environment at once.

For each variant, a matching subdirectory in your package install is expected. So in this case, these directories are expected:

~/packages/maya/2014/platform-linux ~/packages/maya/2014/platform-osx ~/packages/maya/2014/platform-windows

If you are building/installing a package (rez-build, rez-release) then these directories are created for you, and the installation process installs into them. At runtime, when you use rez-env, the correct variant is chosen automagically. So lets say my maya package had the following commands:

def commands(): env.PATH.append("{root}/bin")

"{root}" is a special variable that expands out to the installed variant location. So, assuming I created this env:

]$ rez-env maya platform-linux

..the package's commands would translate into this bash code:

export PATH=$PATH:~/packages/maya/2014/platform-linux/bin

..and the linux variant of your maya package would have its binaries correctly exposed on PATH.

Please be aware that there are also a set of "implicit" packages (configurable) that are always added to the resolve when you use rez-env. You can check what these are with the "rez-config" tool, which prints out rez config settings (taking a look at the source file rezconfig.py is also recommended, it contains all the defaults, and has comments explaining every setting). Typically the platform is included in this implicit list, so if you were on linux, you might find that trying to do "rez-env maya platform-osx" will fail with a conflict. That's because the implicit platform-linux dependency would be clashing with your platform-osx request.

Hth, A

On Thu, Jan 21, 2016 at 10:51 AM, Doug Epps < notifications@github.com> wrote:

i'm sure this is basic, but I'm not easily grokking it.

I'm looking to make a cross-platform "maya" package, so each platform needs a different path to the maya install dir.

I feel like: variants = [ ["platform-osx", "platform-win", "platform-linux"] ]

or something is along the right lines, but with that I get: maya-2014 /Users/DougEpps/packages/maya/2014/platform-osx (NOT FOUND, local)

or is there a way in the commands() to find out the context (arch, platform, etc) I'm running under and put the config in there ?

if rez.os == "osx": path = "/Applications/Autodesk" elif rez.os == "win": path = "c:/Program Files"

Seems like this is definitely something considered already, I'm just not seeing how to deal with it.

Also looking for a little help with what rez-build and/or rez-install/release do.

Fired up for rez, just need to understand it a little better !

— Reply to this email directly or view it on GitHub https://github.com/nerdvegas/rez/issues/291.

— Reply to this email directly or view it on GitHub < https://github.com/nerdvegas/rez/issues/291#issuecomment-173690884>.

— Reply to this email directly or view it on GitHub https://github.com/nerdvegas/rez/issues/291#issuecomment-173698033.

— Reply to this email directly or view it on GitHub < https://github.com/nerdvegas/rez/issues/291#issuecomment-173719335>.

— Reply to this email directly or view it on GitHub https://github.com/nerdvegas/rez/issues/291#issuecomment-173723702.

[dougepps]

We could put an example like this in the repo yes, could be useful for prebuilt installations such as maya. However there are studios out there that run the entire build through rez, even for large packages such as maya and houdini (my own studio included). So if this kind of package were added to the repo I would name it something like "maya_prebuilt".

Just to pull on this a bit.

Somehow you’ve got different paths to the actual “it came from autodesk or sidefx” binary files and libraries, yes ?

Even if you’re putting them on a central server, unless you’re just doing things with clever mountings, those directors are different.

So I’m wondering where you specify that path difference. Or if you’re "building the whole maya”, does that mean part of your CMake is copying binaries around so that they get installed properly, and so the specifics of those paths are in there ?

I get that for your builds (i.e. stuff you compile) you’re building, but I’m still not grasping the generic-case of “files from a vendor”. Sorry if I’m being dense.

-doug

A

On Jan 21, 2016, at 1:46 PM, allan johns notifications@github.com wrote:

For a platform-dependent package such as maya, you typically want your entire payload to be specifically for that platform - bins, libs etc. Even for an internally developed package, you typically don't want part of that to be platform-agnostic and part platform-dependent. In cases where the code is the same across platforms - for eg perhaps a python-based executable is the same on linux and windows - the build process will just install duplicates to each platform-specific variant, but that in itself doesn't cause any problems.

It's much more common to have a case where a package has a 'common' part, and an application-specific part; consider a crowd system that has a common library, and integration for both Maya and Houdini. Currently the best way to deal with that is to split your project into several parts - common, maya and houdini - and just have the maya and houdini packages depend on the common package.

"""Also, I just put a print statement in the commands() for ~/packages/maya/2014/package.py and ~/packages/maya/2014/platform-osx/package.py and I’m only seeing the “generic” one."""

~/packages/maya/2014/platform-osx/package.py is not a valid location for a package. The package.py is the package definition file. It is always located at the base of the package install, regardless of the variants the package has. Packages are always located at ~/packages/PKG_NAME/VERSION/package.py.

It might help to run "rez-build -i" in this hello_world example:

https://github.com/nerdvegas/rez/tree/master/repository/hello_world_py/1.0.0 . You can play around with the package.py there and see how adding variants affects the layout of the installed package. The user manual I gave a link to earlier also goes into detail on how a package is laid out on disk.

"""In a similar vein, your example {root}/bin pre-supposes that all the binaries are in the ~/packages/maya/2014 somewhere, whereas I’d like to just add a directory to the PATH."""

You can append/prepend/set whatever you like to PATH. Example:

def commands(): import platform path="/svr/maya/{this.version}/%s/bin" % platform.uname[0] env.PATH.append(path)

Rez also provides a 'system' object for you:

def commands(): path="/svr/maya/{this.version}/{system.platform}/bin" env.PATH.append(path)

However, if you do this, and you don't use variants, you are hiding your package's platform dependency from rez. That isn't wrong per se, just something to know. Of course, you could do both - have platform-based variants, and append absolute paths outside of your payload area to PATH as shown above.

"""I.e ~/packages/maya/2014/package.py sets a python variable mayaRoot and then ~/packages/maya/2014/package.py uses that to construct paths."""

package.py files are not to be treated like normal python files. They do not import each other or anything like that. They are standalone package definition files - in fact there is still support for package.yaml (yaml is the old format and no longer recommended to use).

Hth A

On Thu, Jan 21, 2016 at 12:26 PM, Doug Epps notifications@github.com wrote:

This kind of makes sense to me.

But I’m fuzzy on how to do the basic “this is how maya should be run cross-platform”.

I’m imagining that there will be a lot of “shared code” between a package’s setups among the platforms, so I’d like to have the bulk of that be in my “generic” package.py ( ~/packages/maya/2014/package.py) and then have just the info needed for different platforms in the os specific location.

Is that possible ?

I.e ~/packages/maya/2014/package.py sets a python variable mayaRoot and then ~/packages/maya/2014/package.py uses that to construct paths.

In a similar vein, your example {root}/bin pre-supposes that all the binaries are in the ~/packages/maya/2014 somewhere, whereas I’d like to just add a directory to the PATH.

Also, I just put a print statement in the commands() for ~/packages/maya/2014/package.py and ~/packages/maya/2014/platform-osx/package.py and I’m only seeing the “generic” one. (even though I have to have the platform-osx in there or it complains, so it’s seeing it somehow).

thanks again. Once I crack this, I think I’m in-love.

On Jan 21, 2016, at 11:57 AM, allan johns notifications@github.com wrote:

Hey Doug,

It will probably help to take a look at the (old) user manual: http://nerdvegas.github.io/rez. Some of the finer details are old (the commanline tools have changed, and the "wrapper" chapter is not relevant anymore) but a lot of that doc still fairly accurately describes what rez does, what variants are and so on. I'm in the process of writing the new docs, but it's a lot of work.

To answer your question directly:

So yes, variants are very often used for cross platform packages, and especially if you are building your package, this is the right way to go. You have the syntax a bit wrong though, this is more what you're after:

variants = [ ["platform-linux"], ["platform-osx"], ["platform-windows"] ]

This describes 3 variants in a package. Each variant is a list of package requirements, that get added to the main "requires" list. Think of variants as different flavors of the same package. "platform" is actually a rez package, and "linux", "osx" and "windows" are the version numbers(!). It's done this way because it gives us a nice property - it makes it impossible to mix together packages for different platforms, because the dependency resolving algorithm makes that impossible - two different versions of a package cannot be present in the same environment at once.

For each variant, a matching subdirectory in your package install is expected. So in this case, these directories are expected:

~/packages/maya/2014/platform-linux ~/packages/maya/2014/platform-osx ~/packages/maya/2014/platform-windows

If you are building/installing a package (rez-build, rez-release) then these directories are created for you, and the installation process installs into them. At runtime, when you use rez-env, the correct variant is chosen automagically. So lets say my maya package had the following commands:

def commands(): env.PATH.append("{root}/bin")

"{root}" is a special variable that expands out to the installed variant location. So, assuming I created this env:

]$ rez-env maya platform-linux

..the package's commands would translate into this bash code:

export PATH=$PATH:~/packages/maya/2014/platform-linux/bin

..and the linux variant of your maya package would have its binaries correctly exposed on PATH.

Please be aware that there are also a set of "implicit" packages (configurable) that are always added to the resolve when you use rez-env. You can check what these are with the "rez-config" tool, which prints out rez config settings (taking a look at the source file rezconfig.py is also recommended, it contains all the defaults, and has comments explaining every setting). Typically the platform is included in this implicit list, so if you were on linux, you might find that trying to do "rez-env maya platform-osx" will fail with a conflict. That's because the implicit platform-linux dependency would be clashing with your platform-osx request.

Hth, A

On Thu, Jan 21, 2016 at 10:51 AM, Doug Epps < notifications@github.com> wrote:

i'm sure this is basic, but I'm not easily grokking it.

I'm looking to make a cross-platform "maya" package, so each platform needs a different path to the maya install dir.

I feel like: variants = [ ["platform-osx", "platform-win", "platform-linux"] ]

or something is along the right lines, but with that I get: maya-2014 /Users/DougEpps/packages/maya/2014/platform-osx (NOT FOUND, local)

or is there a way in the commands() to find out the context (arch, platform, etc) I'm running under and put the config in there ?

if rez.os == "osx": path = "/Applications/Autodesk" elif rez.os == "win": path = "c:/Program Files"

Seems like this is definitely something considered already, I'm just not seeing how to deal with it.

Also looking for a little help with what rez-build and/or rez-install/release do.

Fired up for rez, just need to understand it a little better !

— Reply to this email directly or view it on GitHub https://github.com/nerdvegas/rez/issues/291.

— Reply to this email directly or view it on GitHub < https://github.com/nerdvegas/rez/issues/291#issuecomment-173690884>.

— Reply to this email directly or view it on GitHub https://github.com/nerdvegas/rez/issues/291#issuecomment-173698033.

— Reply to this email directly or view it on GitHub < https://github.com/nerdvegas/rez/issues/291#issuecomment-173719335>.

— Reply to this email directly or view it on GitHub https://github.com/nerdvegas/rez/issues/291#issuecomment-173723702.

— Reply to this email directly or view it on GitHub https://github.com/nerdvegas/rez/issues/291#issuecomment-173732906.

[nerdvegas]

Hi Doug, did you get my reponse? I don't know why it isn't showing here in the comment thread in github. In case you didn't:

Just to pull on this a bit. Somehow you’ve got different paths to the actual “it came from autodesk or sidefx” binary files and libraries, yes? Even if you’re putting them on a central server, unless you’re just doing things with clever mountings, those directors are different.

Yes - no mounting magic.

_So I’m wondering where you specify that path difference. Or if you’re "building the whole maya”, does that mean part of your CMake is copying binaries around so that they get installed properly, and so the specifics of those paths are in there ?_

Not sure I follow.

We have a 'houdini' package. As part of its build, it installs houdini into, say, /tools/linux/houdini/{version}. The commands in the package look like:

def commands(): path = "/tools/{system.platform}/houdini/{this.version}" env.PATH.append(path + "/bin")

We only do this installation into /tools/linux/* for particularly large packages. For most packages, and for all internally developed packages, the installation goes into the package's {root}. The packages that appear in each variant also appear in the package install path for each variant, so {root} is different for each varian

[dougepps]

Didn’t get it , so thanks for re-sending.

You’re houdini example clarifies it for me I think.

path = "/tools/{system.platform}/houdini/{this.version}"

Is how you find specific things. I could also do:

def commands(): if (system.platform == “BeOS”): path = “/blah/blah/bin” elif (system.platform == “Commodore64”: path = “/other/stuff” env.PATH.append(path)

right ?

I.e. the {variable} syntax works like that ?

On Feb 1, 2016, at 5:26 PM, allan johns notifications@github.com wrote:

Hi Doug, did you get my reponse? I don't know why it isn't showing here in the comment thread in github. In case you didn't:

_ Just to pull on this a bit.

Somehow you’ve got different paths to the actual “it came from autodesk or sidefx” binary files and libraries, yes ?

Even if you’re putting them on a central server, unless you’re just doing things with clever mountings, those directors are different._ Yes - no mounting magic.

So I’m wondering where you specify that path difference. Or if you’re "building the whole maya”, does that mean part of your CMake is copying binaries around so that they get installed properly, and so the specifics of those paths are in there ?

Not sure I follow.

We have a 'houdini' package. As part of its build, it installs houdini into, say, /tools/linux/houdini/{version}. The commands in the package look like:

def commands(): path = "/tools/{system.platform}/houdini/{this.version}" env.PATH.append(path + "/bin")

We only do this installation into /tools/linux/* for particularly large packages. For most packages, and for all internally developed packages, the installation goes into the package's {root}. The packages that appear in each variant also appear in the package install path for each variant, so {root} is different for each varian

— Reply to this email directly or view it on GitHub https://github.com/nerdvegas/rez/issues/291#issuecomment-178295962.

[nerdvegas]

Yep. The "{syntax}" just expands out various objects that are bound to the namespace for you by rez. The most common ones are:

'this': current package. this.root, this.version. 'system': system info. 'request': Dict-like object of packages that were requested 'resolve': Dict-like object of packages that were resolved.

Docs on this are in the works.

A

On Tue, Feb 2, 2016 at 10:43 AM, Doug Epps notifications@github.com wrote:

Didn’t get it , so thanks for re-sending.

You’re houdini example clarifies it for me I think.

path = "/tools/{system.platform}/houdini/{this.version}"

Is how you find specific things. I could also do:

def commands(): if (system.platform == “BeOS”): path = “/blah/blah/bin” elif (system.platform == “Commodore64”: path = “/other/stuff” env.PATH.append(path)

right ?

I.e. the {variable} syntax works like that ?

On Feb 1, 2016, at 5:26 PM, allan johns notifications@github.com wrote:

Hi Doug, did you get my reponse? I don't know why it isn't showing here in the comment thread in github. In case you didn't:

_ Just to pull on this a bit.

Somehow you’ve got different paths to the actual “it came from autodesk or sidefx” binary files and libraries, yes ?

Even if you’re putting them on a central server, unless you’re just doing things with clever mountings, those directors are different._ Yes - no mounting magic.

So I’m wondering where you specify that path difference. Or if you’re "building the whole maya”, does that mean part of your CMake is copying binaries around so that they get installed properly, and so the specifics of those paths are in there ?

Not sure I follow.

We have a 'houdini' package. As part of its build, it installs houdini into, say, /tools/linux/houdini/{version}. The commands in the package look like:

def commands(): path = "/tools/{system.platform}/houdini/{this.version}" env.PATH.append(path + "/bin")

We only do this installation into /tools/linux/* for particularly large packages. For most packages, and for all internally developed packages, the installation goes into the package's {root}. The packages that appear in each variant also appear in the package install path for each variant, so {root} is different for each varian

— Reply to this email directly or view it on GitHub < https://github.com/nerdvegas/rez/issues/291#issuecomment-178295962>.

— Reply to this email directly or view it on GitHub https://github.com/nerdvegas/rez/issues/291#issuecomment-178751291.

[jasoncscott]

This is an old issue, and labeled as a question, which I believe has been answered. Should we close this?