On Tue, Mar 8, 2016 at 4:22 PM, Michael Merickel <mmeri...@gmail.com> wrote: > > On Tue, Mar 8, 2016 at 5:55 PM, Marc Abramowitz <msabr...@gmail.com> wrote: >> >> To be honest, I'm not sure I want to be solely responsible for it myself >> either. I was hoping that if it was under the Pylons project, that would >> allow more people to chip in, as needed. > > > The Pylons Project repositories still need to have a maintainer / point of > contact to manage releases and code reviews. That is not something that is > automated. Aside from kotti and webtest the project releases and code > reviews are managed almost 100% by me, Bert and Tres with a lot of people > popping their heads in once in a while along with Steve doing yeoman's work > on documentation. We are always excited for anyone looking to help but > that's just the way things are right now so taking on another project really > does need to have someone willing to learn the codebase and work on it when > necessary. > >> >> Someone a while back also mentioned the possibility of just pulling >> whatever bits of PasteDeploy that Pyramid needs into Pyramid itself. I have >> not looked into what that would entail however. Might be a lot of code and I >> don't think the PasteDeploy code is super well-tested so that might involve >> writing lots of tests. > > > I think with the advent of montague by Joe Rosenbaugh as well as 12-factor > app design I know, personally, that I'm ready to start having a conversation > about what to do in this space. PasteDeploy is definitely a point of > contention amongst the users of Pyramid and bringing it into core will not > be happening. It's already an issue that our CLI tools are dependent on the > ini files and I think these are things that everyone wishes were fixed but > we've never had a discussion on coming up with a standard solution because > everyone has their own use-cases to deal with.
Are people using the 12-factor app design widely, particularly the part about putting settings in environment variables? I looked into doing that but but came up with more problems than advantages: 1. It claims envvars are more secure, but anybody can run 'cat /proc/N/environ ; echo' whereas file permissions can keep them from reading. 2. Hierarchical namespaces are useful, and INI at least gives you two: sections and options. Prefixing envvar keys makes then inconveniently long. 3. INI keys are private to the process, while environ vars can clash with some other program you didn't know about. Thus requiring prefixes, which leads to #2. 4. The biggest problem with declarative settings is parsing the text values and formatting them, and envvars are no better at this than INI settings. (I use FormEncode to validate/convert settings on startup.) I also looked at TOML and it was intriguing (especially the datetime type), but again, I couldn't find enough pluses to switch to it, and my codeveloper couldn't either. Still, it would be nice to have something cleaner than INI and PasteDeploy in Pyramid's default, but I also don't know what would be a good candidate for that. -- Mike Orr <sluggos...@gmail.com> -- 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 post to this group, send email to pylons-devel@googlegroups.com. Visit this group at https://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/d/optout.
