-
Notifications
You must be signed in to change notification settings - Fork 35
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
Merge with the environs library? #12
Comments
@sloria This looks really neat! First time seeing marshmallow and just glanced at
|
Thank you for your feedback.
So, do you use your if env('FEATURE_X_ENABLE'):
do_x() vs. feat_x_enabled = env.bool('FEATURE_X_ENABLED')
#...
if feat_x_enabled:
do_x() In the former case, the schema API makes a little more sense. I'm still unsure if it justifies the added API surface. I'll open an issue for discussion.
Yep, we'll definitely have proxied variables in environs 1.0.
OK, sounds likes a plan. I've made you a collaborator on environs. No pressure at all to do anything with it; just wanted to open the door for collaboration. |
Thanks for the response! Yeah I typically use the first-style. But perhaps the second-way really is the best so maybe the schema is unnecessary. With that in mind, maybe the |
Perhaps, but I quite like the conciseness of |
Agree, either way or even keeping both is fine. It'll still be a lot cleaner than before. |
Closing this. Thanks again for the feedback! Btw, I've released environs 1.0, which adds support for proxied variables. |
Thank you for envparse. I liked its API so much that I implemented a successor library, environs, which uses marshmallow to do the heavy lifting for casting, validation, and serialization.
environ's API is near-identical to envparse, with a few differences:
decimal
,datetime
,date
,timedelta
, anduuid
Env
constructor. (Env(FOO=bool)
). This was intentional; I did not see an advantage in having the redundant API.env('VARNAME', cast=str)
; you must doenv.str('VARNAME')
. Again, the intention was to avoid redundant API.preprocessor
andpostprocessor
are not supported. Any pre- or post-processing can happen in a custom parser function.env
files (yet). Up for discussion here: Read .env files sloria/environs#1environs was mostly written as a proof-of-concept, though at this point it is stable enough to use (it's only ~100SLOC after all).
I wonder if we could reduce duplication of effort by merging these two libraries. I haven't yet thought about the particulars; just wanted to open the table for discussion first.
Thoughts?
The text was updated successfully, but these errors were encountered: