Hello,
I'm writing to explore an issue with the idea behind being able to use
multiple file formats for settings, as is supported
by plaster, and combining pyramid applications.
Pyramid applications might be combined. Either
through Configurator().include() or by a manual
merging. If 2 pyramid applications are combined,
A and B, and each uses a different setting file format,
it is my understanding that, given only the existing
set of libraries, the resulting application,
application C, must have only 1 setting file format.
That means that either the users of A or the users
of B must switch to a different file format for settings
if they are to use the enhanced application C.
Speaking with a system administrator's hat on, it
is always annoying and sometimes dangerous when
and upgrade forces alteration of a working configuration.
Switching configuration formats presents a
not-necessarily-trivial obstacle to upgrading.
A less intrusive alternative would be to be able
to continue to use both A's and B's existing
settings files, with a relatively simple modification:
excising the "common components"
from one or the other of A's or B's setting's file.
Common components being things both A and B configure,
such as WSGI or logging related settings.
It seems that with the right loader and the right
URI plaster could support loading settings from
multiple files each with a different format.
Whether it is a good idea to do this is another
question. I suppose it all depends on the actual
circumstances. As I write I'm realizing that
what I care about is whether the possibility of
loading settings from multiple files of
different formats is a possibility that could
be addressed using plaster should the need arise.
I would like to, eventually, do something so that
my application uses a YAML based settings file.
It is because my application is composed of multiple
plugins configured with Configurator.include(),
and is designed to be able to be combined with
other Pyramid applications, that I'm thinking about
this as something that might someday need to be
addressed.
I'm wondering if anybody has explored the issue above,
or whether it is not seen as a problem, and would
like to hear people's thoughts.
Regards,
Karl <k...@karlpinc.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to pylons-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/pylons-devel/20201126075810.611aaae1%40slate.karlpinc.com.
