-
-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CLI to get modules installation path #658
Comments
Wait I can't tell if QUOKKA is a joke or an actual command? You are saying you want an equivalent of |
I am glad you asked!! |
In this context, it is a command that would basically print the SHPC internal (fueled by Quokka energy, I forgot to state this in the above description!) |
please refresh your page, I have done some in-comment bug fixes! |
So I am asking for an equivalent of |
That way it is possible to get |
(I know, by now you will be lost in quokka cuteness!!!) |
omg, indeed they are adorable! If this is for a specific module, what about |
It is for the root dir of the module tree:
|
In this example, we need
To enable the module tree within the module system. |
The end result being:
|
So you want shpc to do something the module software already does? |
Nope, look at this:
I want SHPC to be able to spit out the path that |
We already have:
So you could probably just add a flag that says "only give me the actual value" fairly easily. |
We could even make the single value the default, and then have the extra identifier provided with a flag (that probably is more expected). |
Oh yes good point, thank you Vanessa! For this specific one, the preferred approach for me would still be to provide SHPC users with a more concise CLI to get the value of this specific config, on the ground that it is used at SHPC setup time. In alternative, yes, a |
My proposal would be: $ shpc config get module_base
/home/vanessa/Desktop/Code/shpc/modules And I don't think we have a good reason to repeat the attribute name. What do you think? |
Quokka approves! |
Would you like me to put in a PR or do you want to take a shot? |
If there is no rush, I should be able to get into this in about a couple of weeks .. wrapping up with my current work projects..finishing off next Friday..! Otherwise feel free to go ahead :-) |
Perfect, I will keep you posted! |
Thank you @marcodelapierre ! Apologies I couldn't jump on it - I'm in full steam work mode. I think I wrote/deleted 5k + lines of code today, I'm shoving down dinner, and am going right back to it. |
No worries, please enjoy some personal time Vanessa!! I will be cheering for your code hackathon....go Vanessasaurus, lead the team to coding heaven!! |
Hi @vsoch,
yesterday I was starting to think how the container story for the talk in a month might look like; in my mind the central topic is user experience.
So, provided the dependencies are available (container runtime, module system, Python), I started to picture myself showing how to get up and running with container modules in the simplest possible way, and ...
Hold on a minute....have I just said
QUOKKA
?!Yes, I have .. because I have realised that
QUOKKA
would be a nice addition to the SHPC CLI functionalities.As you see,
QUOKKA
is a way for SHPC to provide the shell with the path where the modulefiles are installed.We have this for
views
:So that one can do
But we don't have this for non view configurations.
My temptation would be to be consistent with
views
and just introduceshpc get
, however this is currently being used to provide the path to the SIF image for a given registry. How should we proceed?Note that right now one can get the path to a SIF image by means of:
So I am tempted to say we could deprecate this old command meaning, and update to the suggestion above.
Or we could update the current
get
CLI to become e.g.get_sif
or similar.Last point: right now the full CLI looks like:
Should we update it so that the
shpc
CLI embeds themodule use
bit? (is it even doable from Python, asmodule
is a shell function?) We can leave as is, just a thought.What are your thoughts? Thank you!
The text was updated successfully, but these errors were encountered: