I have used parsing '__file__' to get at a custom section 'archive'
used by a backup routine (read-only database credentials).
I'm now moving more and more things into environment variables, which
are more Docker Compose and CI (Continuous Integration) friendly when
different deployments need different configurations. I've got a
general routine called from 'main()' that looks for variables like
'APPNAME__sqlalchemy__url' and overwrite the corresponding setting
('sqlalchemy.url').I had to use double underscores because dots aren't
allowed in environment variable names. The initial double underscore
is to distinguish "APPNAME__foo" (an envvar overriding an arbitrary
setting) from "APPNAME_FOO" (an envvar used for a non-setting
purpose). I didn't want to count on upper/lowercase recognition or
translation.
Longer-term I'm debating whether to switch to a JSON file or go
completely to default values overriden by envvars. The reason I
haven't yet is there are some fifty settings, some for middleware, and
some that would be split (e.g., four unchanging settings plus one or
two deployment-specific/secret settings): I don't want to put the
entire group into envvars, but at the same time I don't want to split
the group either. So I've kept the INI file until I feel more certain.
(But the INI file has only the '[app:main]" section, parsed by
'pyramid.paster.get_appsettings()'. The logging configuration is a
separate INI file parsed by 'logging.config.fileConfig()'.
On Tue, Mar 4, 2025 at 8:00 AM Jonathan Vanasco <[email protected]> wrote:
>
> This was a fast fix. Thanks all. Code is below in case anyone else needs to
> do something similar:
>
> Background:
> * a test.ini used an alternate port for CI tests in the background
> * some tests started failing due to port mismatches.
> * i caught the port mismatch thanks to a little vanity 'will be serving on'
> message
> * this app starts in a deeply nested url, so I print out in the main setup a
> message like:
>
> "APPLICATION will be serving on:
> http://host:port/path/to/the/nested/start/page";
>
> -----
>
>
> from pyramid.scripts.common import get_config_loader
>
> _config_loader = get_config_loader(config_uri)
> assert "server:main" in _config_loader.get_sections()
> _server_settings = _config_loader.get_settings("server:main")
> _host = _server_settings.get("host")
> _port = _server_settings.get("port")
> _admin_server = "http://%s:%s"; %( _host, _port)
> if _admin_server != config.registry.settings["admin_server"]:
> print("* ====================================================== *")
> print("Updating `admin_server` setting:")
> print("app:main file states: %s" %
> config.registry.settings["admin_server"])
> print("server:main calculates: %s" % _admin_server)
> print("* ====================================================== *")
> config.registry.settings["admin_server"] = _admin_server
>
>
> print(
> "Application will be serving on: "
> + config.registry.settings["admin_server"]
> + config.registry.settings["application_settings"]["admin_prefix"]
> )
>
> On Tuesday, March 4, 2025 at 9:24:42 AM UTC-5 Jonathan Vanasco wrote:
>>
>> Thanks. I'll reparse in main!
>>
>> On Monday, March 3, 2025 at 4:00:51 PM UTC-5 Michael Merickel wrote:
>>>
>>> If you access the plaster loader directly you can query the whole file.
>>> However, if you wait until your pastedeploy app factory then everything is
>>> hidden from you and you have to parse the file again yourself. The file
>>> path is contained in the `global_config["__file__"]` key passed to the app
>>> factory so it is pretty straightforward to do it.
>>>
>>> On Mar 3, 2025, at 08:50, Jonathan Vanasco <[email protected]> wrote:
>>>
>>> Is there any way to access the configured host/port in the
>>> `project/__init__.py::main(global_config, **settings):` block? Those vars
>>> are set in the `[server:main]` block of a `config.ini` file - not
>>> `[app:main]`. It looks like I can determine them in the context of a
>>> request due to the implementation details of WSGI, but I need to access
>>> them in the initial app setup.
>>>
>>> It seems like they may not be passed onto Pyramid and I would need to parse
>>> the configuration file and pull it out myself.
>>>
>>> --
>>> 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 [email protected].
>>> To view this discussion visit
>>> https://groups.google.com/d/msgid/pylons-discuss/f24eac45-de01-4ed1-812b-1f5d31a85081n%40googlegroups.com.
>
> --
> 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 [email protected].
> To view this discussion visit
> https://groups.google.com/d/msgid/pylons-discuss/66c7bab8-34fc-4b94-9085-a14fcffbf339n%40googlegroups.com.
--
Mike Orr <[email protected]>
--
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 [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/pylons-discuss/CAH9f%3DupCZX2dYa3gfMK7Av7BuTKHZorVmvWC_yEDokaW7qCG2w%40mail.gmail.com.
