Improve and unify developer shell interfaces#47492
Improve and unify developer shell interfaces#47492psakievich wants to merge 35 commits intodevelopfrom
Conversation
|
As for a shell with the build environment, what's wrong with I've never used To me it would make more sense if:
|
Yes I agree. Adding a I started working on this yesterday because some SNL staff mentioned they use this, but it's not great, and they haven't used I would propose the following for Stage 1. Make it compatible with environments and Overall I think the I don't like that it is essentially wrapping |
|
I think I might give up on the prompt for this PR. I think adding that plus a I personally would classify this as a bug fix since there was no real reason for this command to not work with environments in the past. @haampie I've updated the help section. This command does not appear in the docs 😬 . Not sure I want to add it right now given I consider it a candiadate to be reworked or deleted. |
I tried consolidating but I am not convinced it will work correctly
ae257a4 to
3f88278
Compare
|
Left a review comment, still need to take a closer pass for Windows concerns, but this should at least unblock the CI. |
Co-authored-by: John W. Parent <[email protected]>
johnwparent
left a comment
There was a problem hiding this comment.
Partial review, still need to look closer at the dev_build and location commands.
Trying this on Windows results in an error, tracing that down now.
| pass | ||
| except subprocess.CalledProcessError: | ||
| pass | ||
| raise SpackError("Unknown shell type being used on Windows") |
There was a problem hiding this comment.
Do you want me to add support for CMD?
There was a problem hiding this comment.
Hmm what do you think is best? I could just punt on windows for this PR and you could do a follow on? Otherwise likely yes? I never use windows so I don't really know what is best here.
There was a problem hiding this comment.
I can also just commit directly to this PR if you're cool with that, shouldn't take long
There was a problem hiding this comment.
Yeah that is fine if the changes are small. If I run into too many more windows issues then I think we should break it into two PR's since I can't really test windows behavior outside of CI at the moment.
There was a problem hiding this comment.
Agreed, that's reasonable.
| else: | ||
| try: | ||
| output = subprocess.check_output( | ||
| 'powershell -Command "echo $PSVersionTable"', universal_newlines=True |
There was a problem hiding this comment.
This will always pass (fine if we don't want to support CMD), as the powershell executable is always in the path unless a user removed it explicitly.
I think something like:
pproc_name = psutil.Process(os.getppid()).name()
is_power_shell = bool(re.fullmatch('pwsh|pwsh.exe|powershell|powershell.exe', pproc_name))
With a better regex would be best.
lib/spack/spack/prompt.py
Outdated
| mods = EnvironmentModifications() | ||
|
|
||
| if shell == "fish" or shell == "pwsh" or shell == "bat": | ||
| # requires a function and can't be set with os.environ |
There was a problem hiding this comment.
bat can be set from env variables
Co-authored-by: John W. Parent <[email protected]>
Signed-off-by: psakiev <[email protected]>
Signed-off-by: psakiev <[email protected]>
Signed-off-by: psakiev <[email protected]>
Signed-off-by: psakiev <[email protected]>
Signed-off-by: Phil Sakievich <[email protected]>
Signed-off-by: psakiev <[email protected]>
ca72e17 to
f56c825
Compare
Signed-off-by: psakiev <[email protected]>
Signed-off-by: psakiev <[email protected]>
Signed-off-by: psakiev <[email protected]>
Updated Scope:
This PR adds functionality to
spack dev-buildandspack build-envto increase compatibility and add a longstanding external featurebuild-env-diveto spack core.build-env-dive [spec]is a shell function thatThe features added are:
spack build-env--divefor diving into the build-envspack build-env --statusfor people using shells that don't have a changed prompt (aka fish, powershell)--cdfor navigation with subshell commands, (reproducesspack cdas a precursor to the dive/cmd)spack dev-build--promptand unify code for the--drop-inwithspack build-env --divespack dev-divealias to replacebuild-env-divecompletelyExample developer workflow
Original message:
There is really no reason why
spack developanddev-buildshouldn't play along with each other.dev-buildjust assumes it can't work in an environment. This PR makes it sodev-buildwill look for matching develop specs in a concrete environment.We could optionally make it do a
spack add && spack developif they don't exist but I think that is too far reaching.We have constantly been re-writing a build-env-dive shell function that
Item 1 is already in place with
spack dev-buildso rather than write a whole new funciton, I think we should make them compatible.That said I think the
dev-buildinterface is a little clunky for howbuild-env-divehas been used and I think it needs to be improved, but it might just be doable through aliases.Things I want to add still: