You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the way config objects work is that a user runs fppm config --generate, fills in the proper fillables, and then runs fppm config --apply to generate the output config files. However the apply step seems like it could be automated, if we require that the output metavar be included in any config object.
@LeStarch 's rationale is that this will make sure users do not forget to run fppm config --apply if they modify a variable in a fillable. However, I have reservations about the requirement of the output metavar; it could be too restricting to have to tell package developers where files are supposed to go.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Currently, the way config objects work is that a user runs
fppm config --generate
, fills in the proper fillables, and then runsfppm config --apply
to generate the output config files. However the apply step seems like it could be automated, if we require that theoutput
metavar be included in any config object.@LeStarch 's rationale is that this will make sure users do not forget to run
fppm config --apply
if they modify a variable in a fillable. However, I have reservations about the requirement of theoutput
metavar; it could be too restricting to have to tell package developers where files are supposed to go.Thoughts on this concept?
Beta Was this translation helpful? Give feedback.
All reactions