search

AcademySoftwareFoundation / rez

An integrated package configuration, build and deployment system for software
https://rez.readthedocs.io
Apache License 2.0
953 stars 340 forks source link

Leftover / Orphaned environment variables in child shells #50

Open chadrik opened 10 years ago

chadrik commented 10 years ago

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. This is one of the reasons that I'm not a fan of the source command, since it can wreak total havok on the environment in ways that rez cannot easily track (aside from the fact that it breaks promise of parity between various shells).

nerdvegas commented 10 years ago

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 notifications@github.comwrote:

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/nerdvegas/rez/issues/50 .

chadrik commented 10 years ago

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.

chadrik commented 10 years ago

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.

nerdvegas commented 10 years ago

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 notifications@github.comwrote:

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/nerdvegas/rez/issues/50#issuecomment-33198499 .