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
This isn't an uncommon pattern - could be useful to allow some parameters to take their input from an environment variable. There are some unresolved questions around naming, though:
What should all variables be prefixed with? The program name has remained a fairly flexible concept - it can be a script name script.py, a module name test.script, or manually set by the user. This is not the best thing for creating concise and scoped variable names. Maybe only enable environment variables if the user provides a prefix to arguably.run()?
What if there is an existing environment variable the user wants to connect to a parameter? Is there a concise way of doing this?
Would this only be useful for options, or could positional parameters also work?
The text was updated successfully, but these errors were encountered:
Current plan for implementing this: In arguably.run(), take in a dict[str, list[str]] that maps a short environment variable name (like SERVER_IP) to a list of fully-qualified names ["MYSERVERAPP_RUN_SERVER_IP", "MYSERVERAPP_CHECK_SERVER_IP"]. The alternatives:
Don't have this feature at all
Make this Annotated[]
Fit this in the docstring, somehow.
Of these alternatives, option 3 is most attractive - while a little clunky, it requires documenting this behavior in the docstring, which is a good thing.
This isn't an uncommon pattern - could be useful to allow some parameters to take their input from an environment variable. There are some unresolved questions around naming, though:
script.py
, a module nametest.script
, or manually set by the user. This is not the best thing for creating concise and scoped variable names. Maybe only enable environment variables if the user provides a prefix toarguably.run()
?The text was updated successfully, but these errors were encountered: