Update documentation etc. to use uenv start --view instead of uenv view

[msimberg]

No description provided.

[msimberg]

@jgphpc could you clarify what the requirements are here? Is the /user-tools/activate script not going to work correctly with the view loaded at start? Is it a requirement to source the activate script?

[jgphpc]

At the time of doc writing, this was the only way but now, loading 2 views is working fine:

uenv start prgenv-gnu/24.11:v1,linaro-forge/24.0.2:v1 -v forge,prgenv-gnu:default
uenv start prgenv-gnu/24.11:v1,e0e79f5c3e6a8ee0 -v forge,prgenv-gnu:default

which nvcc
/user-environment/env/default/bin/nvcc

which ddt
/user-tools/env/forge/bin/ddt

so it's fine to remove that part.

[msimberg]

Thanks @jgphpc! I've updated this to load both uenvs and views in one command. Please have a look to see if it's sane to you.

[msimberg]

Is there someone who knows if these activations still work with the new uenv? Does reframe need changes to support loading a view at uenv start-time?

@ekouts you might know best what's supported/required?

[bcumming]

Reframe has support for loading views at start time.
There is a view parameter that can be configured in the extra/reframe.yaml file that specifies which view(s) to load.

[bcumming]

see the cp2k recipe for example:
https://github.com/eth-cscs/alps-uenv/blob/main/recipes/cp2k/2024.3/gh200/extra/reframe.yaml

[msimberg]

Thanks. Updated (all the prgenv-gnu recipes). If I understand correctly, these recipes would need to be rebuilt and deployed with a new version to be able to use the updated reframe.yaml files, yes? (Though all the recipes older than 24.11 probably don't benefit from a rebuild.)

From my perspective this can wait for the next version bump of the prgenv-gnu uenvs, though it wouldn't hurt to have a prgenv-gnu which works with the new uenv. Feels a bit strange to bump it to v2 with a non-user-facing change, but maybe it doesn't matter. Preferences?