--user-mods-dir does not handle relative paths correctly #1642
Comments
|
Okay, from some playing around with this, I gather that this was set up so that --user-mods-dir works analogously to the testmods directory in a test, but relative to the primary component's (I think) cime_config/usermods_dirs directory. While I see a little rationale for that, I mainly find it unintuitive, particularly since it isn't documented. I'd find it much more intuitive if relative paths were taken as relative to the current directory, since this is typical unix behavior and it would better support user-mods directories that some user has created and put in some arbitrary location. |
|
@ekluzek @bandre-ucar and @olyson - having played around with this for CLM, do you have any feelings on how this should work? |
|
I would prefer relative paths that are relative to the current directory. --user-mods-dir /glade/p/work/oleson/clm4_5_16_r243/components/clm/cime_config/usermods_dirs/clm/clm5_OutputCrop I would do this: --user-mods-dir clm/clm5_OutputCrop which is how it was intended to work? And documentation about where usermods are supposed to go (components/clm/cime_config/usermods_dirs/clm). |
|
Ah, I think I see the problem, and also how to make it support both "true" relative paths and paths relative to the primary component's cime_config... I'll work on a fix. |
Fix relative path for --user-mods-dir Converts user_mods_dir to abspath earlier This is needed for relative paths to be handled correctly. The problem with the former placement was that the working directory had been changed to be inside the new case directory at that point, which made os.path.isdir(user_mods_dir) False because it was interpreted as being relative to the wrong starting point. Test suite: scripts_regression_tests on yellowstone: all passed except ERP.f45_g37_rx1.A.yellowstone_intel, which failed initially due to what looked like a system problem; it passed upon rerunning it (Ran testing on branch rebased onto 8517405) Also did some manual testing of various forms of --user-mods-dir: Relative path: ./create_newcase --case test_usermods_0607f --compset A --res f45_g37_rx1 --user-mods-dir ../src/drivers/mct/cime_config/testdefs/testmods_dirs/drv/default Absolute path: ./create_newcase --case test_usermods_0607g --compset A --res f45_g37_rx1 --user-mods-dir /Users/sacks/cime/src/drivers/mct/cime_config/testdefs/testmods_dirs/drv/default Testmods: ./create_test --test-root . SMS.f45_g37_rx1.A.roo2_gnu.drv-default Path relative to the primary component's cime_config/usermods_dirs: ./create_newcase --case test_usermods_0607h --compset A --res f45_g37_rx1 --user-mods-dir wjs_test where I had created a user_mods dir: src/drivers/mct/cime_config/usermods_dirs/wjs_test Test baseline: N/A Test namelist changes: none Test status: bit for bit Fixes #1642 User interface changes?: none Code review:jedwards
ghost
removed
the
If I try to create a case like this:
I get:
This works if I give an absolute path, but if I give a relative path, it tries to make the path relative to
/Users/sacks/cime/src/drivers/mct/cime_config/usermods_dirs/(for this case... probably some other location in other cases), rather than relative to the current directory.This was previously issue #497 , which was supposedly fixed by #501.
The text was updated successfully, but these errors were encountered: