-
Hello, First I'd like to thank you for developing this. I've been migrating some of my workflows to rez recently and it's been going pretty well. I'm still figuring out what's the best way of using rez - developing, deploying, runtime environments. One thing I am unsure about is how to use rez to create a package development environment - one where I can interactively develop, test, tweak package in package's git repo, e.g. in a development branch. For more context, I'm mostly looking at develpoing Python packages and DCC-specific assets, like Houdini's HDAs. I use I think I'm looking for something like Another workflow, although not ideal, would be to do a local build, then resolve that environment, do changes in it and then copy those changes back to the git repository. This involves some extra work, so I'd like to avoid it if possible. The closest thing I've found is to do A manual workaround for me would be to create a "env script" I'd source before the development. This script would contain the same env vars as rez's I've also tried running Hope my question makes sense to you. I secretly hope there's some simple solution for this, or a flag I've missed. I use rez 2.111.3 on Windows. Best, |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 2 replies
-
Still wrapping my head around this. After a bit of reading it looks like I'd like to resolve into an unbuilt package (where I'd do the development, in package's git repo). It'd be something like pip's editable install. Another avenue I'm exploring to do so is prepending my project's working directory into Am I approaching this correctly? It looks like many people do a local build with Some notes for my future self:
|
Beta Was this translation helpful? Give feedback.
-
Would anybody be willing to share their Python package development workflow? Let's say that I have a package that depends on numpy. I specify that in the From that environment I can do what I need - editing files in package's repository, running tests etc. If I add more dependencies, then I need to update both |
Beta Was this translation helpful? Give feedback.
-
On linux, the way I used to do it is to simply symlink the local package content back to the source code directly. This can be done in the build script of the package and triggered only on local builds. This way, you can |
Beta Was this translation helpful? Give feedback.
On linux, the way I used to do it is to simply symlink the local package content back to the source code directly. This can be done in the build script of the package and triggered only on local builds. This way, you can
rez-env yourTool
and stay inside this environment to run the tool you are developping as often as you want, and this is updated everytime you hit the save button in your IDE.On Windows however, I have yet to figure out how to achieve a similar workflow.