Is there a way pass arguments to the package install's overrides

[herronelou]

Hello.
I have noticed that Variant.install() has an overrides argument, which is then passed to the repo's install_variant() method.

I'm looking for a way to override certain package attributes at build time when certain conditions are met, but it doesn't seem like it's possible from the command line, and I didn't figure out if doable from the custom build_command either, as it seems the package.py is generated separately from the build (by the install).
So far I'm thinking a new build_system and/or build process plugin might be the cleanest way to go but that also seems like a lot of work for a small change.

Motivation behind the question for context:
My end goal is to automate a potential workflow that is currently a fairly manual process.
For testing packages during development with other users and/or on the farm, we have created a different directory on the network on which we install these packages. We have set a package filter to ignore any package that has *.dev.* in the version.
When a dev wants to make a dev build, they change the version number to x.x.x.dev.{ticket}, then run rez-build --install --clean -p /path/to/dev/area. We don't really want them to commit this version change into the code, although it would be fine, we don't want it to end up in main, so then one step would be to revert the package,py version change.
On the testing side, it's already sorted, as we do our own resolves in oder to test a user would simply need to refer to the package by exact version: package==x.x.x.dev.{ticket} and it gets included.

What I would like instead of the multiple steps above, would be for the devs to simply run rez-build --clean --install --dev {ticket}, and my build system would modify the path to the correct location (easy to do via build script), and override the version to append .dev.{ticket} to it.

[nerdvegas]

I think you should be able to do this fairly easily with a package preprocessor and envvar: https://github.com/AcademySoftwareFoundation/rez/wiki/Package-Definition-Guide#package-preprocessing . You could then go: ``` ]$ DEVTICKET={ticket} rez-build --clean --install ``` You'd have a preprocessor then use the value of DEVTICKET (if set) to alter both the install path and package version. Hth A

…

On Fri, Sep 9, 2022 at 3:36 AM Erwan Leroy ***@***.***> wrote: Hello. I have noticed that Variant.install() has an overrides argument, which is then passed to the repo's install_variant() method. I'm looking for a way to override certain package attributes at build time when certain conditions are met, but it doesn't seem like it's possible from the command line, and I didn't figure out if doable from the custom build_command either, as it seems the package.py is generated separately from the build (by the install). So far I'm thinking a new build_system and/or build process plugin might be the cleanest way to go but that also seems like a lot of work for a small change. *Motivation behind the question for context:* My end goal is to automate a potential workflow that is currently a fairly manual process. For testing packages during development with other users and/or on the farm, we have created a different directory on the network on which we install these packages. We have set a package filter to ignore any package that has *.dev.* in the version. When a dev wants to make a dev build, they change the version number to x.x.x.dev.{ticket}, then run rez-build --install --clean -p /path/to/dev/area. We don't really want them to commit this version change into the code, although it would be fine, we don't want it to end up in main, so then one step would be to revert the package,py version change. On the testing side, it's already sorted, as we do our own resolves in oder to test a user would simply need to refer to the package by exact version: package==x.x.x.dev.{ticket} and it gets included. What I would like instead of the multiple steps above, would be for the devs to simply run rez-build --clean --install --dev {ticket}, and my build system would modify the path to the correct location (easy to do via build script), and override the version to append .dev.{ticket} to it. — Reply to this email directly, view it on GitHub <#1373>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMOUSV4QUMCUBKGPFIVJQDV5IP3RANCNFSM6AAAAAAQH7D3JU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Jawabiscuit]

I found recently that these are also worth considering when doing preprocessing.

https://github.com/AcademySoftwareFoundation/rez/wiki/Configuring-Rez#package_definition_build_python_paths
https://github.com/AcademySoftwareFoundation/rez/wiki/Configuring-Rez#package_definition_python_path

[herronelou]

Thanks. I've started playing with the pre-processor since asking this question and I think I'm going to go this way, but use argparse and sys.argv to infer the type of build. I'm also planning to use it so that only releases can have local cache, to avoid accidentally caching packages susceptible to changing.