Previously, --divvy was a top-level argument, coming right after looper and before any command subparsers. But I thought the --divvy arg would only be needed for run and runp, so I tried moving the argument to those parsers.
However, then I get some issues, like:
looper inspect
Read from dotfile (/home/nsheff/code/atac_ebna2/.looper.yaml)
...
Looper version: 1.2.0-dev
Command: inspect
Traceback (most recent call last):
File "/home/nsheff/.local/bin/looper", line 10, in <module>
sys.exit(main())
File "/home/nsheff/.local/lib/python3.7/site-packages/looper/looper.py", line 753, in main
compute_env_file=select_divvy_config(filepath=args.divvy),
AttributeError: 'Namespace' object has no attribute 'divvy'
So apparently we are using the args.divvy to construct the project even if. I guess it is easier that way...but it seems more appropriate to not bother with the computing configuration for commands that don't require it.
I was just wondering if you think this makes sense @stolarczyk and if we can just simplify things to not load a computing environment for every command, or what you think...
Previously,
--divvy
was a top-level argument, coming right afterlooper
and before any command subparsers. But I thought the--divvy
arg would only be needed forrun
andrunp
, so I tried moving the argument to those parsers.However, then I get some issues, like:
So apparently we are using the
args.divvy
to construct the project even if. I guess it is easier that way...but it seems more appropriate to not bother with the computing configuration for commands that don't require it.I was just wondering if you think this makes sense @stolarczyk and if we can just simplify things to not load a computing environment for every command, or what you think...