Open kwinkunks opened 1 year ago
I agree.
Making this a bug because the error you get on Azure (root is /prog/komodo
) is so obscure
(2023.06.03-py38) [mtha@s034-rgs0002 ert-internal-examples]$ komodoenv --no-update ~/kenv-ert
Traceback (most recent call last):
File "/prog/komodo/2023.06.03-py38-rhel7/root/bin/komodoenv", line 8, in <module>
sys.exit(main())
File "/prog/komodo/2023.06.03-py38-rhel7/root/lib/python3.8/site-packages/komodoenv/__main__.py", line 195, in main
args = parse_args(args)
File "/prog/komodo/2023.06.03-py38-rhel7/root/lib/python3.8/site-packages/komodoenv/__main__.py", line 153, in parse_args
assert args.root.is_dir()
AssertionError
PAssing --root /prog/komodo
is the workaround.
As of #68 komodoenv first checks for the existence of /prog/komodo
before defaulting to /prog/res/komodo
, so should now be easier to use on Azure. Although this is not as robust as the suggestions in this issue.
If Komodo releases are not located in
/prog/res/komodo
then trying to automatically use an env for a newkomodoenv
results in an error like:/prog/res/komodo/2023.02.b3-py38-rhel7' is not a valid komodo release
In my case, the root is
/prog/komodo/2023.02.b3-py38-rhel7
.Perhaps it's best to keep things super explicit, but it might be nice to try detecting the komodo root from the combination of
KOMODO_RELEASE
andPATH
.For reference, here's how we do this in
komodo
. (It would be even nicer if Komodo set an environment variable with the path to the root -- see linked issue.)