Comments (4)
Well, the argument goes that if no package touched LD_LIBRARY_PATH, then no
package is affected by it. If a package is adversely affected, it should be
setting LD_LIBRARY_PATH, and not assuming anything about the environment
it's run in. This is true whether rez-env is invoked from within a rez
shell or not.
Consider - if a package is adversely affected by LD_LIBRARY_PATH, then what
happens when we rez-env from a normal shell using this package, and
LD_LIBRARY_PATH already happens to be set in a way that breaks it? The
package breaks! The package is broken, not Rez.
I've never seen extraneous variables cause a problem in the past. Is there
some case that's causing a problem at Luma? Could you go into more detail,
give an example perhaps, maybe there's something I'm missing.
A
On Thu, Jan 23, 2014 at 6:22 PM, Chad Dombrova [email protected]:
so there's this whole other topic that i have not brought up which i see
as rez's achilles heel. i think it can be solved if rez can have some
control over the environment it sets up (i.e. no source command).the problem is simple:
$ echo $MAYA_LOCATION
$ rez-env maya$ echo $MAYA_LOCATION
/usr/autodesk/maya2014.51-x64
$ rez-env nuke$ echo $MAYA_LOCATION
/usr/autodesk/maya2014.51-x64rez makes no effort whatsoever to remove old variables.
This is a pretty big problem. what if you drop into a shell with a resolve
that sets LD_LIBRARY_PATH, then drop into another shell below that which
does not. LD_LIBRARY_PATH is still set, potentially along with dozens of
other variables which are not relevant and potentially harmful to the
current resolve.I believe if we can keep track of which variables rez sets, then we can
unset all of those before the next resolve.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/50
.
from rez.
Let's say that Maya needs to set LD_LIBRARY_PATH
in order to work. then from the same shell we rez-env nuke
which does not need LD_LIBRARY_PATH
setup in order to work, because it finds its libraries relative to its install directory, for example. at this point it could very well read the libtiff
from that left-over LD_LIBRARY_PATH
which would be bad.
Packages assume they are starting from a clean slate. Some packages will not work correctly if a variable like LD_LIBRARY_PATH
is set, but should we really expect every package to unset every variable that might cause a problem?
the same argument applies to PYTHONPATH
or any other resource path that could be used from multiple packages.
our current system handles this and we have not rolled out rez into production yet, so no issues to report yet, but this is definitely a concern that might halt its roll-out.
as i mentioned, if we track the variables set by each shell -- which we already do -- we should be able to unset them prior setting the new environment. i think it's pretty doable.
from rez.
Consider - if a package is adversely affected by LD_LIBRARY_PATH, then what happens when we rez-env from a normal shell using this package, and LD_LIBRARY_PATH already happens to be set in a way that breaks it? The package breaks! The package is broken, not Rez.
yes, if LD_LIBRARY_PATH
is set outside of rez what you describe could occur, but if it was set using rez, than we can and should remove it. if a studio uses rez appropriately they can gain the full benefits, if they choose to set a bunch of env vars outside of its control, then yes, there may be problems.
from rez.
Well, I don't see anything wrong with adding this as a configurable option,
I'm not deeply against it. If you have a use case then we could add this
behaviour - as I said though as long as its configurable.
On Thu, Jan 23, 2014 at 9:28 PM, Chad Dombrova [email protected]:
Consider - if a package is adversely affected by LD_LIBRARY_PATH, then
what happens when we rez-env from a normal shell using this package, and
LD_LIBRARY_PATH already happens to be set in a way that breaks it? The
package breaks! The package is broken, not Rez.yes, if LD_LIBRARY_PATH is set outside of rez what you describe could
occur, but if it was set using rez, than we can and should remove it. if a
studio uses rez appropriately they can gain the full benefits, if they
choose to set a bunch of env vars outside of its control, then yes, there
may be problems.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/50#issuecomment-33198499
.
from rez.
Related Issues (20)
- "process ID out of range" error when using rez-env from within a Docker container with namespaced PIDs HOT 3
- Rez auto delete rxt temp files make subprocess rez-context faild. HOT 1
- Ephemerals should be available in late binding functions HOT 1
- Add attribute in late bindings to detect when it is run under rez-test
- Feature request: "proxy" packages that support direct editing of files without rebuild HOT 3
- Shell type plugin can resolve incorrectly in rez.system on Linux. HOT 1
- rez-pkg-cache the case of pachage'name HOT 2
- TSC Meeting 2024-05-16
- Combined packages (multi packages) fail on windows
- Rez use powershell to render houdini will lost $HIP and $F HOT 8
- build_requires with @late can not run rez env -b to create build env
- Inconsistent normalization of config paths can break handling of local packages path
- Unrecognised package repository plugin: 'memory' HOT 1
- TSC Meeting 2024-06-20
- Using aliases in Powershell muffles exit code
- Backslash in rezconfig.py causing errors on fresh windows installations. HOT 1
- _VersionRangeParser regex don't match `range_desc` example HOT 3
- Pip remaps - error when install HOT 1
- rez-env python -- which python failed HOT 1
- rez-bundle throws subprocess.Popen error
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rez.