Open marcodelapierre opened 3 years ago
My thinking for this was that (for the most part) I think people would be likely to want to add envars after install - if the default in settings always generates the file, that's easy to do - just edit the file! Now for your case if you want to just nix the entire thing, I think you would just set the settings environment file to be null.
Ah I see! Of course this is subjective :)
My thought was in the spirit of using almost only SHPC to handle the setup of Container Modules. So users willing to add envvars would define them in the recipe, then (re-)install with SHPC.
But if you think that some people would prefer to add envars independently from SHPC, then it makes complete sense - and ignore this Issue :-)
And actually I agree that your current solution is more flexible from a user perspective!
I figure it doesn't hurt to have, but it could hurt to not. But let's leave this issue open for future users to comment on!
agree!
One minor, last thought I had while scrolling through the current setup for envfile.
Always having the --envfile "..." in the modulefile, even when it's not used, makes it quite less readable. I was then wondering whether it should be made conditional?
...Actually I see it's already conditional in the modulefile templates:
{% if envfile %}
. So it's just about ensuring thatenvfile
is set to null if no envs are defined in the container yaml?