config in config files?
42 views
Skip to first unread message
Chris Withers
Aug 3, 2017, 2:08:30 PM8/3/17
to Pylons
Hi All,
Once more determined to actually build something in pyramid, going to
settle on a REST server to feed a web front end and likely a cli tool too.
Looking for advice on best bits to use, but in the meantime, looking at:
https://docs.pylonsproject.org/projects/pyramid_ldap/en/latest/#usage
...I see a bunch of config in a python file, which is what I hate most
about Django.
I would expect to see AuthTktAuthenticationPolicy's secret and ldap
queries and password all coming from a config file.
What's the pattern for this with Pyramid? Also curious what the best way
is to structure an app beyond a trivial one-file-r like that ;-)
In my head, I'm surprised to see the configurator growing ldap_* methods
(I guess added by the config.include('pyramid_ldap')?)
My ageing memory has something in it about .ini format files, but I know
there was some talk of making the config file format pluggable, how did
that pan out?
Excitedly yours,
Chris
Once more determined to actually build something in pyramid, going to
settle on a REST server to feed a web front end and likely a cli tool too.
Looking for advice on best bits to use, but in the meantime, looking at:
https://docs.pylonsproject.org/projects/pyramid_ldap/en/latest/#usage
...I see a bunch of config in a python file, which is what I hate most
about Django.
I would expect to see AuthTktAuthenticationPolicy's secret and ldap
queries and password all coming from a config file.
What's the pattern for this with Pyramid? Also curious what the best way
is to structure an app beyond a trivial one-file-r like that ;-)
In my head, I'm surprised to see the configurator growing ldap_* methods
(I guess added by the config.include('pyramid_ldap')?)
My ageing memory has something in it about .ini format files, but I know
there was some talk of making the config file format pluggable, how did
that pan out?
Excitedly yours,
Chris
Bert JW Regeer
Aug 3, 2017, 2:12:49 PM8/3/17
to pylons-...@googlegroups.com
You can grab it from a .ini or wherever when using the latest Pyramid with plaster support (write your own loader to load it from yaml files for example).
I guess it is not entirely clear, but here’s docs for the two methods: https://docs.pylonsproject.org/projects/pyramid/en/latest/narr/environment.html#using-pastedeploy
**settings is provided by your launcher, pserve will use plaster and call main() on your application that is registered with setup tools and provide the settings dictionary to do with as you please.
Bert
--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discus...@googlegroups.com.
To post to this group, send email to pylons-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/fd1d91f4-8e6b-cf46-232d-4b9e05f0ac9f%40withers.org.
For more options, visit https://groups.google.com/d/optout.
Chris Withers
Aug 3, 2017, 3:12:08 PM8/3/17
to pylons-...@googlegroups.com
Hi Bert,
Long time no speak, hope you're well!
On 03/08/2017 19:12, Bert JW Regeer wrote:
> You can grab it from a .ini or wherever
"or wherever" preferable ;-)
> when using the latest Pyramid
> with plaster support (write your own loader to load it from yaml files
> for example).
What's plaster?
> I guess it is not entirely clear, but here’s docs for the two
> methods: https://docs.pylonsproject.org/projects/pyramid/en/latest/narr/environment.html#using-pastedeploy
>
> **settings is provided by your launcher, pserve will use plaster and
> call main() on your application that is registered with setup tools and
> provide the settings dictionary to do with as you please.
Hoping plaster is something cool, not a typo...
cheers,
Chris
> <mailto:pylons-discus...@googlegroups.com>.
> <https://groups.google.com/d/msgid/pylons-discuss/A70D0947-EE8B-4254-869F-5B123509C1F4%400x58.com?utm_medium=email&utm_source=footer>.
Long time no speak, hope you're well!
On 03/08/2017 19:12, Bert JW Regeer wrote:
> You can grab it from a .ini or wherever
> when using the latest Pyramid
> with plaster support (write your own loader to load it from yaml files
> for example).
> I guess it is not entirely clear, but here’s docs for the two
> methods: https://docs.pylonsproject.org/projects/pyramid/en/latest/narr/environment.html#using-pastedeploy
>
> **settings is provided by your launcher, pserve will use plaster and
> call main() on your application that is registered with setup tools and
> provide the settings dictionary to do with as you please.
cheers,
Chris
> To post to this group, send email to pylons-...@googlegroups.com
> <mailto:pylons-...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pylons-discuss/A70D0947-EE8B-4254-869F-5B123509C1F4%400x58.com
> <https://groups.google.com/d/msgid/pylons-discuss/A70D0947-EE8B-4254-869F-5B123509C1F4%400x58.com?utm_medium=email&utm_source=footer>.
Steve Piercy
Aug 3, 2017, 3:27:13 PM8/3/17
to pylons-...@googlegroups.com
On 8/3/17 at 8:12 PM, ch...@withers.org (Chris Withers) pronounced:
>What's plaster?
https://docs.pylonsproject.org/projects/plaster/en/latest/
--steve
------------------------
Steve Piercy, Soquel, CA
>What's plaster?
https://docs.pylonsproject.org/projects/plaster/en/latest/
--steve
------------------------
Steve Piercy, Soquel, CA
Chris Withers
Aug 3, 2017, 5:04:38 PM8/3/17
to pylons-...@googlegroups.com
On 03/08/2017 19:12, Bert JW Regeer wrote:
> You can grab it from a .ini or wherever when using the latest Pyramid
> with plaster support (write your own loader to load it from yaml files
> for example).
>
> I guess it is not entirely clear, but here’s docs for the two
> methods: https://docs.pylonsproject.org/projects/pyramid/en/latest/narr/environment.html#using-pastedeploy
>
> **settings is provided by your launcher, pserve will use plaster and
> call main() on your application that is registered with setup tools and
> provide the settings dictionary to do with as you please.
With Steve's pointer to plaster, this sounds great, but how do I tell
> with plaster support (write your own loader to load it from yaml files
> for example).
>
> I guess it is not entirely clear, but here’s docs for the two
> methods: https://docs.pylonsproject.org/projects/pyramid/en/latest/narr/environment.html#using-pastedeploy
>
> **settings is provided by your launcher, pserve will use plaster and
> call main() on your application that is registered with setup tools and
> provide the settings dictionary to do with as you please.
pserve to use plaster?
cheers,
Chris
Chris Withers
Aug 3, 2017, 5:06:07 PM8/3/17
to pylons-...@googlegroups.com
Hey Steve,
Hope it's all going well too :-)
On 03/08/2017 20:27, Steve Piercy wrote:
> On 8/3/17 at 8:12 PM, ch...@withers.org (Chris Withers) pronounced:
>
>> What's plaster?
>
> https://docs.pylonsproject.org/projects/plaster/en/latest/
Cool, more out of curiosity than anything: how came montague had to be
re-implemented as plaster rather than just being polished up to 1.0?
cheers,
Chris
Hope it's all going well too :-)
On 03/08/2017 20:27, Steve Piercy wrote:
> On 8/3/17 at 8:12 PM, ch...@withers.org (Chris Withers) pronounced:
>
>> What's plaster?
>
> https://docs.pylonsproject.org/projects/plaster/en/latest/
re-implemented as plaster rather than just being polished up to 1.0?
cheers,
Chris
Chris Withers
Aug 3, 2017, 5:07:17 PM8/3/17
to pylons-...@googlegroups.com
can be triggered from settings, but how would I do the same for the
ldap* methods?
cheers,
Chris
Michael Merickel
Aug 3, 2017, 5:09:43 PM8/3/17
to Pylons
pserve and all pyramid tools use plaster under the hood as of 1.9.
plaster was a significant enough redesign from montague that it felt like it warranted being a new library.
- Michael
--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to pylons-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/e339c944-7a62-d6cc-bf86-0a707cb68a15%40withers.org.
Bert JW Regeer
Aug 3, 2017, 5:21:09 PM8/3/17
to pylons-...@googlegroups.com
You’d have to write some custom code to automatically make those calls, but you can use the settings dictionary to pull out the values you need.
cheers,
Chris
--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discus...@googlegroups.com.
To post to this group, send email to pylons-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/117c5e87-7148-0d1f-f781-2dcff35a86a6%40withers.org.
Mike Orr
Aug 4, 2017, 12:04:36 PM8/4/17
to pylons-...@googlegroups.com
The INI file is just a convenience for developers who like that
format. Putting 'pyramid.includes - foo' in the INI file is equivalent
to calling 'config.include("foo")' in the main function. And both of
those are just conveniences for whatever initialization routine and
arguments 'foo' requires. The nice thing about INI is it provides four
things in one central place:
1. The application settings, which combine Pyramid's settings,
third-party dependency configuration, and your own custom settings.
2. WSGI server settings, if using 'pserve'.
3. Logging configuration, if using 'pserve' or you call
'logging.config.FileConfig'.
4. Other sections. 'pserve' doesn't use those but your application can
define its own sections if it wants to.
Some people put all their includes in the INI file so that they can
configure everything in one place. Others put "essential" includes and
settings in their main function -- things that must be set a certain
way or the application will break -- and "optional" includes and
settings in the INI file -- things that can be customized by the user.
However, it's sometimes difficult to make a clear distinction between
the two, especially if the same include has some essential arguments
and some optional ones. That leads people back to putting everything
in the INI file.
One disadvantage of INI is that everything comes in as strings. The
Pyramid docs show routines parsing these themselves. I don't like
this: it means validation bugs will happen there, perhaps deep in an
obscure request. So at the beginning of my 'main' routine I call a
'process_settings' function to validate them, convert them to their
proper types, and fill in default values. I tried both Formencode and
Colander and ended up using Formencode, because Colander separates
validation and conversion but I found too many cases where they have
to be done together or I allow two types (e.g., int or None, string or
None). If you don't convert the types, then any routine that uses the
settings has to, incluidng dependencies, so some libraries have a
second initialization function that does that (SQLAlchemy's
'engine_from_config' vs 'create_engine').
--
Mike Orr <slugg...@gmail.com>
format. Putting 'pyramid.includes - foo' in the INI file is equivalent
to calling 'config.include("foo")' in the main function. And both of
those are just conveniences for whatever initialization routine and
arguments 'foo' requires. The nice thing about INI is it provides four
things in one central place:
1. The application settings, which combine Pyramid's settings,
third-party dependency configuration, and your own custom settings.
2. WSGI server settings, if using 'pserve'.
3. Logging configuration, if using 'pserve' or you call
'logging.config.FileConfig'.
4. Other sections. 'pserve' doesn't use those but your application can
define its own sections if it wants to.
Some people put all their includes in the INI file so that they can
configure everything in one place. Others put "essential" includes and
settings in their main function -- things that must be set a certain
way or the application will break -- and "optional" includes and
settings in the INI file -- things that can be customized by the user.
However, it's sometimes difficult to make a clear distinction between
the two, especially if the same include has some essential arguments
and some optional ones. That leads people back to putting everything
in the INI file.
One disadvantage of INI is that everything comes in as strings. The
Pyramid docs show routines parsing these themselves. I don't like
this: it means validation bugs will happen there, perhaps deep in an
obscure request. So at the beginning of my 'main' routine I call a
'process_settings' function to validate them, convert them to their
proper types, and fill in default values. I tried both Formencode and
Colander and ended up using Formencode, because Colander separates
validation and conversion but I found too many cases where they have
to be done together or I allow two types (e.g., int or None, string or
None). If you don't convert the types, then any routine that uses the
settings has to, incluidng dependencies, so some libraries have a
second initialization function that does that (SQLAlchemy's
'engine_from_config' vs 'create_engine').
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pylons-discus...@googlegroups.com.
> To post to this group, send email to pylons-...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pylons-discuss/fd1d91f4-8e6b-cf46-232d-4b9e05f0ac9f%40withers.org.
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pylons-discus...@googlegroups.com.
> To post to this group, send email to pylons-...@googlegroups.com.
> To view this discussion on the web visit
--
Mike Orr <slugg...@gmail.com>
Chris Withers
Aug 7, 2017, 3:01:52 AM8/7/17
to pylons-...@googlegroups.com
On 03/08/2017 22:20, Bert JW Regeer wrote:
>
>>>> I guess it is not entirely clear, but here’s docs for the two
>>>> methods:
>>>> https://docs.pylonsproject.org/projects/pyramid/en/latest/narr/environment.html#using-pastedeploy
>>>>
>>>>
>>>> **settings is provided by your launcher, pserve will use plaster and
>>>> call main() on your application that is registered with setup tools and
>>>> provide the settings dictionary to do with as you please.
>>>
>>> With Steve's pointer to plaster, this sounds great, but how do I tell
>>> pserve to use plaster?
>>
>> Sorry, also forgot to ask: I can see how the config.include(...) call
>> can be triggered from settings, but how would I do the same for the
>> ldap* methods?
>
>
> You’d have to write some custom code to automatically make those calls,
> but you can use the settings dictionary to pull out the values you need.
Okay, stepping back, if I wanted to replace my production.ini with a
>
>>>> I guess it is not entirely clear, but here’s docs for the two
>>>> methods:
>>>> https://docs.pylonsproject.org/projects/pyramid/en/latest/narr/environment.html#using-pastedeploy
>>>>
>>>>
>>>> **settings is provided by your launcher, pserve will use plaster and
>>>> call main() on your application that is registered with setup tools and
>>>> provide the settings dictionary to do with as you please.
>>>
>>> With Steve's pointer to plaster, this sounds great, but how do I tell
>>> pserve to use plaster?
>>
>> Sorry, also forgot to ask: I can see how the config.include(...) call
>> can be triggered from settings, but how would I do the same for the
>> ldap* methods?
>
>
> You’d have to write some custom code to automatically make those calls,
> but you can use the settings dictionary to pull out the values you need.
production.yaml, what do I need to change and where?
cheers,
Chris
Michael Merickel
Aug 7, 2017, 11:22:32 AM8/7/17
to Pylons
You need to write a loader for plaster that can handle yaml files and the loader needs to satisfy the plaster.interfaces.IWSGIProtocol. No one has stepped up quite yet to write any alternate file format loaders so you're on your own there. The ability to do so is what's supported now.
That loader defines everything from how to parse the yaml file for settings all the way up to how to invoke the main function of the app. For example, the main(global_config, **settings) spec is defined by pastedeploy and is not required by any other loaders. If you want to keep that same spec then you probably have a fair amount of code you need to rip out of pastedeploy (montague already did this work).
cheers,
Chris
--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to pylons-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/f6d70888-ca0e-5c7b-02a1-85c2e59e5b77%40withers.org.
Reply all
Reply to author
Forward
0 new messages