How to use the existing rez enviroment

[PBLNRAO Kiran]

Hi All,

I am new to rez and was assigned to do RnD in implementing rez in our studio.

Currently we are already have a rez environment setup by one of the our client at a centralised location in our network and is mapped to a network drive. we will be receiving the updated packages from client itself and we just update our rez packages and internally we developed a launcher tool as per requirements and will be launched using a context files generated from our end as per our company needs.

Now we want to use the same rez environment and include our inhouse developed tools also to be rez packages.

when i created a hello_word package for testing. i am getting below error.

BuildSystemError: No Build system is associated with the path c:/test/hello_world

My implements.

01. Added path to the rez environment so that, now i am able to use below rez commands directly from command prompt.

As per the rez documentation i followed below steps to check.

https://github.com/nerdvegas/rez#quickstart  excluding Intallation part from the link as its already configured.

 

rez-env - used it and got the resolver without error.

tried rez-build platform - package got installed into my local packages folder.

tried rez-build arch - package got installed into my local packages folder. 

tried rez-build os - package got installed into my local packages folder. 

tried rez-build python - Got error - "RezBindError: Could not find executable python"

(May be i dont have administrator rights on the system)

can anyone guide me further whats wrong i am doing.

Suggestions / Thoughts..?

[David Lai]

Hi,

rez-bind python on Windows won’t work, there are some file link issue I remember. You have to write your own python package.

And, rez-bind is going to be deprecated, currently only use that command to build implicit packages (arch, os, platform).

Here’s my python package implementation, 

https://github.com/davidlatwe/rez-miniconda

 

hope this helps :)

PBLNRAO Kiran <pblnra...@gmail.com>於 2020年9月1日 週二，19:46寫道：

--


You received this message because you are subscribed to the Google Groups "rez-config" group.


To unsubscribe from this group and stop receiving emails from it, send an email to rez-config+...@googlegroups.com.


To view this discussion on the web visit https://groups.google.com/d/msgid/rez-config/bc54a427-4aa6-4b0a-a064-5b7d88a89c48n%40googlegroups.com.

--

David Lai  |  Animation Production Pipeline Developer
     GitHub |  github.com/davidlatwe

[brian...@locksmithanimation.com]

David is right, binding packages is being deprecated in favour of "native" packages, which represent software installed on the local system.

Check out:

https://github.com/nerdvegas/rez-recipes

You'll find packages that can be built to get you the standard implicit packages (os, arch, platform) and some of the other foundation packages.

[Pablo Giménez]

Hey David.

Why bind is going to be deprecated?

I find it a great solution to have templates to build packages of software installed in the system.

I have extended some of the functionality of bind in this PR:

https://github.com/nerdvegas/rez/pull/939

Is there any alternative in the roadmap to have templates that build packages for existing tools.

Also we use it in Windows and works perfectly, the thing is we use Rez as a very lightweight layer mainly to enable tools in the PATH, and with rez bind we can pretty much generate simple packages for installed tools quite easily.

I dont see a point of deprecating it if there is no other alternative that improves the functionality provided by bind.

Cheers

P

On Tuesday, 1 September 2020 at 13:06:47 UTC+1 David Lai wrote:

[David Lai]

Hi Pablo,

Deprecating rez-bind wasn't my decision, I found it's being planned in this mail group and confirmed in Rez's Slack channel.

And from what I understand, rez-build can do what rez-bind does and provide rich features. So, I didn't use rez-bind except building os, arch, platform.

Cheers,

David

Pablo Giménez <pabl...@gmail.com> 於 2020年9月1日 週二 下午10:45寫道：

To view this discussion on the web visit https://groups.google.com/d/msgid/rez-config/7b8df798-72cb-4f54-8919-521d260cc0b2n%40googlegroups.com.

[Pablo Giménez]

Hey David.

Sorry I didnt mean you decided it :)

Is just that I dont understand it unless ther is an alternative, I like the fact that you can use bind modules as templates to build other packages, for simple packages is very useful.

For this simple packages build is overkill.

Thanks

P

[Brian Silva]

I don't know if this was part of the decision to deprecate it, but I like the fact that with native packages, you have package.py files just like any other package. That may not matter for things like os and arch, but it's nice for DCC apps and other apps that require configuration.

We implemented a script that discovers all the versions of different software on the local machine, and runs a native package build for each version (we have build_command = False in each package.py, so it's a simple process). We decided to to do this because binding was being deprecated, but IMHO in the end I think it was probably the same amount of work as writing bind modules, and it's more similar to the "usual" process of generating Rez packages.

[Pablo Giménez]

Basically in some way, you re replicating what bind is doing :)

What I have is similar, a function that discovers all versions of an app installed in the system, according with a name convention, this is run inside the bind module, then for every version a package is build.

Basically running build just to get the package install, since it has build_command=False, looks like overkill  :)

But I suppose any system is good as soon as it does the job :)

P

[Allan Johns]

Hey all,

Rez-bind is to be deprecated because package.py files are now expressive enough that they can do everything that bind modules can. Rez already does a lot, and any case we can find where complexity can be removed in favour of a more general solution is a good thing. That's the case here - a "native" package is just a standard package definition like any other, just used to serve a different purpose (interface with existing software on the system). Unfortunately the necessary work hasn't been put into a public repo of these native packages, but there's nothing stopping anyone from doing that! Once this is done, rez-bind just doesn't make sense, as it's another way of doing the same thing, and it confuses people as to which approach they should be taking for interfacing rez with existing software installations.

If you look at how bind modules work you'll see that they're quite simple - they just use the PackageMaker API to construct the installed packages. Functionality like what Pablo describes sounds useful but imo is more appropriate as an external tool that uses the rez API, rather than part of rez itself. On a related note, I do intend to update our github workflows so pip is kept up-to-date once again, which will facilitate external setup-py- based projects that are using rez. I have time set aside every Monday to work on rez currently, this thread has reminded me about Pypi so I think I'll get onto that next week, so stay tuned.

Thanks

Allan

ps - imo a better approach for automatic binding of multiple packages to rez at once, will be to do the following, once the public native package repo is available:

* find stuff on the system you want to bind

* find the corresponding native package

* build and install it

* rinse and repeat

That way there's just one copy of the binding code in existence anywhere, rather than there being native packages, and their rez-bind counterparts.

To view this discussion on the web visit https://groups.google.com/d/msgid/rez-config/165db513-47be-4d33-bb55-524f2fe45b50n%40googlegroups.com.

[Jean-Christophe Morin]

Hey Allan, if you work on having rez in PyPI, could you loop me in? I'd like to review the PRs. I've been pretty much quiet in the last months (I had health issues), but I do have some bandwidth available to review this one.

Thanks!

To view this discussion on the web visit https://groups.google.com/d/msgid/rez-config/CAGMneOeRPzMD%2B31u4jmrz5dBgWRcbuDnUs%3Dqy0ivmuu7r-XKOA%40mail.gmail.com.

--

Jean-Christophe Morin  Software developer jcm...@rodeofx.com  514.397.9999 ext.323   www.rodeofx.com

[Thorsten Kaufmann]

Same here. Very interested in pip and also fixing some of the lower hanging fruits along the way

[Pablo Giménez]

I understand your points Allan.

And make sense.

But probably the cautious thing to do is to wait until a solution to automate packages for installed software is in place and then rez bind will be redundant and therefore can be deprecated.