-
-
Notifications
You must be signed in to change notification settings - Fork 9
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
Provide a configuration class #33
Comments
Looks promising but I think we need to make a significant refactoring on the current implementation to split the responsibility of:
... an do all of it in a 'lazy' way and keeping retro compatibility (and deprecation warnings). I'm planning to do this refactoring for a long time, but I haven't had time to start the development. I hope I can do it, maybe, at the beginning of 2020. |
I started this twice and give up on the process because I'm not finding a good way to implement this refactoring and not break backward compatibility :\ |
Hey @osantana, it wasn't my intention to throw this task at you, but to discuss this idea instead. |
Sure! You are helping me a lot with this development. The main reason why I'm not finding a good approach is not a lack of time but try to get a draft proposal of what I'm planning to do and put here to discuss with you. The main idea is that I think the "Loaders" are getting more responsibility than they need. I think that we need to split these responsibilities in different objects, but, I also know some projects (that I used to work at) who implement new loaders that would break if I make this split in a not-backward-compatible way. I will try to make a transparent transition. If I could not do that I will try to make some helpers for this transition (with some deprecation warnings). In the worst scenario, I will just bump the major version and keep two different development streams for some time. |
Hey @osantana,
I could backport some of these ideas if you like them, or probably the ones that do not introduce incompatible changes. |
Just sharing my thoughts here. This is inspired by GoodConf, and the idea is to allow encapsulating settings inside a structure other than a python module.
Later this object can be used to print settings
Or with
__repl__()
extended
or passed around
We would use the existing plumbing to expose this class, which would be another option to use prettyconf.
I don't like that the
config('debug')
call isn't lazy, so putting it into a class isn't enough:Printing the current project's config settings is not easy, since there is a lot of garbage in any python module or class.
Any thoughts?
The text was updated successfully, but these errors were encountered: