-
Notifications
You must be signed in to change notification settings - Fork 365
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
Global configuration for e.g. auto positionals / shortflags #27
Comments
After thinking a bit I only see the following options:
Still need to research state of the art tho. But suspect the class is the way to go. Bye bye cutesy DSL. |
Hadn't been considering the specifics of how the config data gets into Runner and friends, but:
My suspicion is that in the CLI driven use case, we would build the config, then pass it into each task when the task is executed (thus requiring tasks to always have some initial argument, at which point it's effectively just like a method on a class where that argument is In library use users would be responsible for loading their own config and then doing the same handoff to tasks whenever they get executed. |
Kenneth mentioned how Requests has a similar setup, albeit via a dual API:
This is a lot like what I had in mind originally for the Fabric2 level stuff, except the "unqualified" API would still be able to refer to a threadlocal or similar (probably not by default tho) whereas in Requests it's largely about ability to set defaults. Which, honestly, is kind of the same here; we could say "if you want the ability to globally tickle defaults, you must call methods on an instantiated class. Users with simple needs can still use the API calls directly if they prefer it, users who want to "hook in" can call the method version. |
MOAR COMMENTZ Think the way to go is really what I had in mind before:
|
Thought about this a bunch more recently and started documenting it too. The tl;dr is that it should look like this:
|
Have context object being handed around successfully now, omitted from arg parsing, etc etc. It's an empty object right now, but I will flesh it out as I implement #32. Leaving this open so I ensure it applies to auto-positional + auto-shortflag as subject suggests, once I am done. |
#32 implemented, also the rest of the Right now the context object's inner API is very simply, just a It suffices to enable CLI-flag-driven config, but should get cleaned up for code-level config, and documented. |
Documented things a bit better, not bothering with anything deeper than the |
Would be nice to globally/temporarily set certain default-but-configurable behaviors to specific values.
E.g. in our own test suite, when #23 landed I had to add a bunch of
positional=[]
args to@task
. Would be nice to be able to set that at the test suite level or something.Main hurdle is simply that we want to do away with module level bullshit so this needs to be effected some other way; possibly nothing we support ourselves besides "well, just do this:"
In which case this would just become a "apply that technique to our own tests."
The text was updated successfully, but these errors were encountered: