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
Make it easier to override config file basename #418
Comments
One semi-minor wrinkle: we can't rely on Actually kinda moot, because when I look, I realize So what'll happen is a "full" rebranding of Invoke needs:
Then users would do one of:
And both situations would result in seeking e.g. |
Wrote out a bunch of thoughts on We do still want Kinda mashing two things together here but oh well. |
Looking at this for real now, and realizing that Program and setup.py really have nothing to do with config file loading, because as touched on above, this all needs to work in the absence of any CLI hooks. So if anything, Program should take some cues from the Config class given to it, and not the other way around. However that (moving name/binary into Config) is not strictly required for my needs at the moment (getting a client lib like Fabric 2 able to load Believe all I need for right now is to update Config to use the aforementioned |
Question is whether this should be another kwarg in The former is more obvious and straightforward, but requires a The latter feels kind of strange but allows a subclass to 'hardcode' the value within itself, and is something I've had to do before already (Fabric 2's subclass uses it to determine whether to load SSH conf files in its Actually, there's the third option, a class-level attribute, which feels cleanest anyways even if it's not a pattern I have followed strongly in these codebases (but it's common in e.g. Django and other ORMs for just one example). It's still "defined by the class" but isn't floating around inside the config dicts, which would otherwise imply it can be modified at various config levels (which...it can't...as it determines how many of those other dicts are even loaded!) |
Another angle, the existing Will probably move it to be same as whatever I do for |
Wrote up some DDD that boils down to "use |
Neglected to note in a commit msg that this is done, but...it's done and Fabric 2 is now utilizing the new class attrs for (Whether it should potentially respect both prefixes/filename types, is another matter that can be tackled later...) |
This is technically a spinoff of #276; I don't see code about it in #278.
tl;dr right now the only way to change the
<whatever>.yml
(etc etc) sought by the config stuff is to manually subclass and modifyConfig
, and then to modify a handful of spots annoyingly.Config.__init__
allows overriding the various prefixes, but only individually, and it's moot because one cannot currently override those kwargs inProgram
- only theconfig_class
!This needs to be a lot easier:
/etc/foobar.yml
and~/.foobar.yml
and etc.Program.name
or whatever for this, eitherconfig_kwargs
toProgram
in case users need to modify other kwargs and otherwise do not need to subclass; forced subclassing is inelegant and certainly was not my intention at the time.The text was updated successfully, but these errors were encountered: