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

[doutriaux1]

~ (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]

@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]

@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]

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

[doutriaux1]

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]

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

[aashish24]

@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]

@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]

@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]

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]

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]

Is there a better way to get around this?

[remram44]

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

[jypeter]

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]

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]

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]

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]

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]

thx @remram44 that would be awesome

[doutriaux1]

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

[remram44]

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