This is a great development experience for distributed software. I'm really looking forward to Ubuntu 16.10 -- a lot of things seem to be coming together there.
I had not seen that before, thanks!. The only thing that concerns me about glog is this statement: "The code in this repo is for export only and is not itself under development. Feature requests will be ignored."
I wonder what the differences between these two logging libraries are?
I know Tim wrote loggo specifically to solve some logging problems with Juju, which as the largest open source project in go, and as distributed system management tool puts a lot of pressure on getting good logging in place. But I'm less familiar with seelog's history, and the motivations behind it.
Yea, it's exactly like MongoDB which is also AGPL.
Using the database doesn't impose any restrictions on your software.
Even hacking on juju to add API'S you for your client software doesn't impose restrictions on the client -- it just means you are subject to the AGPL licence source distribution rules on the patched version of Juju.
Mongo is a different beast, because the mongo client has a GPL exception which allows your code, that is linked to the mongo client, to use a different license. This is a friendly exception, that the mongo developers allowed. Without that exception everything using mongo even over the Internet would automatically also be AGPL licensed.
OK, thanks. This was a deal break for us a year ago. The issue was even partly solved and with a few hacks juju did survive reboots, but it was later on removed.
I agree, we have very much approached the problem from that of service administration/management rather than the "build a PaaS"approach. But, I think the "big problem" behind building a heroku style PaaS, is not getting simple scripted deployment to a container -- it is managing relationships between applications, databases, message queues, and other connected services, and I think that is where Juju could be useful to your project.
I'd also be happy to talk more about this any time.
Well, by some definition of legacy, that's always true. If we are learning, using better techniques, and writing better software every day what we wrote yesterday will be "legacy" code... But I don't think that matters, ther will be upgrade paths, support for pylons 1 and tg2, and more cooperation and focus in the development team.
As the current maintainer of TurboGears, I've been thinking a lot about the python web framework world for the last couple of years, and I have been thinking for a long time that there's too much splintering of effort.
One choice to solve that problem would be to all join Django, which is widely used, and has an active developer community. But they have a very strong point of view about how web applications should be developed, and as a result django isn't that flexible.
So, in the end what we need is a strong alternative to Django that is flexible, uses existing libraries to good effect, and just works. By joining together in the Pylons Project around the Pyramid framework, that's just what we're aiming to do.
We are definitely fixing the traversal docs, and they are already much improved over two weeks ago ;)
The responsiveness of Chris and Ben to actually fixing this kind of thing is amazing, and one of the major reasons we thought teaming up with them would be a good idea.
All both pylons and tg have thousands of users on their lists, bfg has dozens of commiters of users, and a growing users list. And between our three frameworks I wouldn't be surprised to see tens of thousands of live sites, and millions of pages served per day. Heck I work on a site with millions of dynamic pages a day served up by turbo gears So, I'd say the facts show a different story than the casual dismissal you want to paint.
There is a lot that can be said for consolidation. And a lot to be said for the team working on pyramid now, so I'm excited in spite of your skepticism.
