New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

uvcdat "executable" should unset env or it might be using the "Wrong" python #730

Closed
doutriaux1 opened this Issue Oct 2, 2014 · 20 comments

Comments

Projects
None yet
7 participants
@doutriaux1
Member

doutriaux1 commented Oct 2, 2014

~ (140) uvcdat --output=""
UVCDAT setup already sourced for this install location.

@jbeezley are you still in charge of setup_runtime or should I re-assign this to @aashish24 or @dlonie

@aashish24

This comment has been minimized.

Contributor

aashish24 commented Oct 2, 2014

@doutriaux1 always assign to me first.. and then I can figure out who is the best person to work on this.

On the issue note, I am not sure what's the issue here? an you explain more? We cannot clear out the environement because we don't know what user has in it. Undoing just what we add is I think some work.

@durack1

This comment has been minimized.

Member

durack1 commented Oct 2, 2014

@doutriaux1 It would be good if the setup scripts checked for existing python/uvcdat paths, and removed other installations.. I agree this would be painful to do, but would also attempt to resolve issues with tangled paths causing users problems in which no coherent error message will easily be able to explain (and consequently the user complains to you about it not working).

@aashish24

This comment has been minimized.

Contributor

aashish24 commented Oct 2, 2014

I am ok with someone else with better idea on how to do it take over -:) this task.

@doutriaux1

This comment has been minimized.

Member

doutriaux1 commented Oct 2, 2014

i think all we need for now is to unsetenv UVCDAT_SETUP_PATH at the begining of the script, it will not fix all tangled issues but should help. I'll take a pass at it if @jbeezley doesn't have time unless @durack1 wants to do it.

@durack1

This comment has been minimized.

Member

durack1 commented Oct 2, 2014

I'm happy to test the *.csh version.. In my bug free, shellshock-unaffected, robust, safe and secure tcsh environment..

@aashish24

This comment has been minimized.

Contributor

aashish24 commented Oct 3, 2014

@doutriaux1 I am not sure about the issue though. Let's say that you open a terminal and run the setup script and now you realized that you ran the wrong one. Why cannot we open another terminal and run the setup script from other location.

@durack1

This comment has been minimized.

Member

durack1 commented Oct 3, 2014

@aashish24 an issue to point out here is that many users (me) have statements which are automagically executed upon initializing a shell (so in my .cshrc).. If you assume that a user has a 'vanilla' environment with nothing but the system python on their path that's one thing, but many centers have default environment initializations that drop the standard /bin or similar in a users path.. Scrubbing these instances of python (and other executables, e.g. ncdump) is key I think.. And what can quickly make these setup scripts very complicated to write (and test).. As it would appear I'm the solo tcsh-er (with a relatively complicated environment config), I'd be happy to test anything you folks manage to tweak..

@doutriaux1

This comment has been minimized.

Member

doutriaux1 commented Oct 3, 2014

@aashish24 @durack1 I have an idea about this, as soon as I get 30mn free i will push a fix that should satisfy everybody. And yes @durack1 is right users have absolutely insane .bashrc/.tcshrc files! Years and years of copying for other users and adding random bits to it!

@remram44

This comment has been minimized.

Contributor

remram44 commented Oct 6, 2014

Currently the UV-CDAT setup_environment scripts add way too much to the environment. I don't think asking people to source it from their bashrc is a good idea, for instance it will replace their python, pip, curl, uuid with uvcdat's. My installation has 260 executables in there, not just the 'uvcdat' command...

The 'uvcdat' script sources setup_runtime.sh anyway, does it make sense to ask people to do it? It's only useful before running Python scripts (to use uvcdat's python) (or we could add a uvcdatpython wrapper).

@aashish24

This comment has been minimized.

Contributor

aashish24 commented Oct 6, 2014

If you can create a application executable for it (for the GUI), that would be great! But for the command like we will need to setup the environment one way or another (even if we use virtual env or conda or something else).

@williams13

This comment has been minimized.

Contributor

williams13 commented Oct 6, 2014

Is there a better way to get around this?

@remram44

This comment has been minimized.

Contributor

remram44 commented Oct 6, 2014

I was considering something like #747. What do you think?

@doutriaux1 doutriaux1 modified the milestones: 2.1, 2.0.0 Oct 7, 2014

@jypeter

This comment has been minimized.

jypeter commented Oct 24, 2014

I found this issue because I was wondering about the UVCDAT already sourced I was getting when starting uvcdat in a window where the UV-CDAT environment was already initialized

I think you can safely remove or comment out the echo line in bin/setup_runtime.csh. No need to confuse the end user with this!

  if ( ${UVCDAT_SETUP_PATH} == ${install_prefix} ) then
    #echo 'UVCDAT setup already sourced for this install location.'
    exit 1
  else
@jypeter

This comment has been minimized.

jypeter commented Oct 24, 2014

There seems to be another sub-thread in this issue. And my advice is do not initialize uv-cdat by default in .cshrc/.bashrc/.profile! I have seen too many side effects of this over the years... :/

I have started writing an alternate version of the instructions found in https://github.com/UV-CDAT/uvcdat/wiki/installation-on-RedHat---CentOS, because I think that the lines like Bash users add source /usr/local/uvcdat/2.0.0/bin/setup_runtime.sh to your ~/.bashrc file are dangerous. The UV-CDAT environment should only be initialized in the terminals where we need UV-CDAT

Unfortunately, my solution based on adding an alias for initialiazing uv-cdat in .cshrc/.bashrc works for bash, but not for tcsh. I have to spend more time on this...

@remram44

This comment has been minimized.

Contributor

remram44 commented Oct 24, 2014

Finishing up #747 is probably the way to go, it would make it safe to always have uvcdat on your PATH. I'll see if I can get back to it soon.

@jypeter

This comment has been minimized.

jypeter commented Oct 24, 2014

Always having UV-CDAT would be OK if basically all you got was python and a few supporting executables, but you get a lot from UV-CDAT's bin directory!

  > find /home/share/unix_files/cdat/versions/cdat_install_uv-2.0.0_x86_64_gcc4_12/bin -executable | \grep -v .py | wc -l
144

Not to mention what you get in the LD_LIBRARY path! And this might lead to just annoying or severe side effects.

As an example of an annoying side effect, I have not been able yet to disable the building of libxml2 in 2.0.0 and I have several non-CDAT programs that seem uncomfortable with that. See below what I get when I start emacs in a terminal where UV-CDAT has been initialized

emacs: /home/share/unix_files/cdat/versions/cdat_install_uv-2.0.0_x86_64_gcc4_12/Externals/lib/libxml2.so.2: no version information available (required by /usr/lib64/librsvg-2.so.2)
emacs: /home/share/unix_files/cdat/versions/cdat_install_uv-2.0.0_x86_64_gcc4_12/Externals/lib/libxml2.so.2: no version information available (required by /usr/lib64/librsvg-2.so.2)
emacs: /home/share/unix_files/cdat/versions/cdat_install_uv-2.0.0_x86_64_gcc4_12/Externals/lib/libxml2.so.2: no version information available (required by /usr/lib64/librsvg-2.so.2)
emacs: /home/share/unix_files/cdat/versions/cdat_install_uv-2.0.0_x86_64_gcc4_12/Externals/lib/libxml2.so.2: no version information available (required by /usr/lib64/librsvg-2.so.2)
emacs: /home/share/unix_files/cdat/versions/cdat_install_uv-2.0.0_x86_64_gcc4_12/Externals/lib/libxml2.so.2: no version information available (required by /usr/lib64/libgsf-1.so.114)
emacs: /home/share/unix_files/cdat/versions/cdat_install_uv-2.0.0_x86_64_gcc4_12/Externals/lib/libxml2.so.2: no version information available (required by /usr/lib64/libgsf-1.so.114)
emacs: /home/share/unix_files/cdat/versions/cdat_install_uv-2.0.0_x86_64_gcc4_12/Externals/lib/libxml2.so.2: no version information available (required by /usr/lib64/libcroco-0.6.so.3)

I'd rather have my users decide when they want to have the standard python/ncdump/etc installed in the system, or the ones provided by UV-CDAT.

@remram44

This comment has been minimized.

Contributor

remram44 commented Oct 24, 2014

We agree completely! This is why my PR is about having only two wrappers on the path, "uvcdatpython" and "uvcdat", which run "python" or VisTrails with the right environment. Nothing can conflict, and even Python gets a separate name.

@doutriaux1

This comment has been minimized.

Member

doutriaux1 commented Oct 27, 2014

thx @remram44 that would be awesome

@doutriaux1 doutriaux1 modified the milestones: 2.2, 2.1 Nov 10, 2014

@aashish24 aashish24 removed their assignment Mar 2, 2015

@doutriaux1

This comment has been minimized.

Member

doutriaux1 commented Mar 5, 2015

ok this issue has become very convoluted, not really sure what it was about any more... I thnk @remram44 addressed this already. If anybody is not satisfied with current status please open a new issue

@doutriaux1 doutriaux1 closed this Mar 5, 2015

@remram44

This comment has been minimized.

Contributor

remram44 commented Mar 5, 2015

This issue is before #747 so probably outdated.
The warning itself was removed recently with #1069.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment