Leftover / Orphaned environment variables in child shells about rez HOT 4 OPEN

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-x64

rez 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.