mmerickel

"just building an API" does not mean you need something more lightweight. It means you have different requirements from a standard full stack web application. You are not dealing with cookies, forms or template rendering but you are still dealing with lots of other problems including authentication, authorization, headers, etc. Pyramid is the ONLY framework I've ever seen that comes with builtin support for dispatching to a view function based on more than just a request method (GET vs POST). In Pyramid GET vs POST is equivalent to any other request property including accept headers, cookies, query strings, etc. Any of these can dictate a different callable. See http://blog.delaguardia.com.mx/pyramid-view-configuration-le... for some examples.

Yeah I mean it's hard to digest comments like "it's not a particularly opinionated framework" against things like "put the ball entirely in your court". They seem to be saying the same thing except you have a different perception of each when you say it.

The problem as I see it is that Pyramid has a lot of extra interfaces and support for things in the core by default (and some concepts that are completely missing from most frameworks like context). So much is there that it's easy to lose sight of how little is actually required. Fundamentally you can write Pyramid apps in 10 lines of code exactly as you would with Flask but that's less interesting for bigger apps and so the docs focus on all the extra features.

I mean if you take the example at the top of http://docs.pylonsproject.org/projects/pyramid/en/latest/ and add in the pyramid_jinja2 library via config.include('pyramid_jinja2') then you basically have views and jinja2 rendering fully baked.

As in the previous example if you get right down to it Pyramid doesn't even have a templating engine! Flask comes with jinja2 built-in! So scaling DOWN to APIs where this is not necessary is an interesting thing..

Well as one of the primary maintainers of Pyramid I'll just say that it's laughable to me all the comparisons to Django as it's much more similar to Flask. The main difference is that it comes with several more "pay only for what you eat" standardized interfaces that you can use to pull things together. It's declarative security concepts are fantastic and completely missing from most other frameworks as well which choose to punt this part to (usually) half-baked addon libraries built to serve one specific use-case.

LucidCharts has a decent import feature for a PostgreSQL schema.

Am I correct in assuming that this is focused only on source distributions right now?

It's unfortunate that this article focuses on running the playbooks/salt states locally. The use of ssh by ansible was the killer feature for me. Configuring a remote cluster without requiring a persistent master. There are valid arguments for maintaining a persistent master, but it's just not in the cards sometimes.

I know salt-ssh exists but it's still alpha, I look forward to seeing how it pans out and whether it can avoid being a second-class citizen to the persistent, non-standard zeromq sockets.

That being said, ansible configuration files are fairly hacky and conceptually just don't quite fit. Some modules support a full yaml-dict whereas others need the string with key=value parts. Sometimes you need to wrap your jinja2 syntax in a yaml string to avoid it being parsed as a yaml dict. There's just some things that don't quite add up so there's definitely room for improvement.

I think I'll live with it until I gain confidence with nix though!

Well from a 12-factor app perspective, having each container dump its output to stderr/stdout is basically perfect as long as docker has a pluggable mechanism for dealing with that output. The "docker attach" API is all that you need, since you can attach prior to starting the container. Then you just need a way to tell docker not to save the logs via some "--disable-logging" option to "docker run" and "docker start".

Currently docker can only mount folders from the host VM into your container. On OS X your host will most likely be VirtualBox. Thus you need to sync the folders from your mac into the VM, and from there into docker.

The hack that docker-osx (https://github.com/noplay/docker-osx) uses has been very effective for me. Basically it mounts your user directory into the vagrant VM at the same path. From there, you can bind-mount any folder in your home directory easily via something like "docker run -i -t --rm -v $(pwd):/srv ubuntu /bin/bash".

I've never seen a recipe documenting whether docker can handle a logrotate. Most daemons require you to HUP them after rotation. In general logrotate is a complete hack in the way it interacts with daemons.

In general you ought to just be able to "docker run" in the foreground from your systemd script, and then stdin/stdout will go into the journal where you can handle things like any other file. This works now, except that the logs are also duplicated into /var/lib/docker.

There are docker commands (docker logs) that are dependent on this format. The primary issue is that if you deal with logs yourself via attaching to the container and piping them somewhere, the logs are still duplicated to these json files. It's unexpected, a waste of space and insecure.

That being said, logrotate would sort of work with caveats since the json files are one entry per line last I checked.

I'm glad to see docker stabilizing but it's very disappointing to not see any changes addressing the logging support that was promised in 1.0 (https://news.ycombinator.com/item?id=7712138 reply by shykes). The infinitely increasing-in-size and unconfigurable logfiles generated by containers in docker are basically a dealbreaker unless you bake your own logging solution into each container and avoid stdin/stdout.

nix (http://nixos.org/nix/) seems to be the solution with the most potential in this area, solving all dependencies at the project level and removing the need for language specific build environments.

It seems you could just pass the stores into the components as data - that's really what they represent. I'm not clear why this approach is eschewing that basic principle in favor of singletons.

That's great to hear - I've dove pretty hard into docker and love it but the logging story has been a dealbreaker for production. Decoupling "create" and "start" has been great when using the Remote API because I can create a container, attach my IO handlers, and then start, removing the need for docker to handle the logs at all (if it supported that). Possibly something like this can be done via the CLI such that docker can just forward the streams into a custom script.

Yes, I've read all of that. I consider this a blocker for production use of docker and releasing a 1.0 RC without solving this is disconcerting (at least as a process wrapper, it still works fine for wrapping an init system that handles everything itself). Especially since, in that thread, shykes said it will be solved prior to 1.0.

If this is an RC, will docker have a way in 1.0 to properly handle stdout/stderr logs captured on the host without just allowing a giant json file to fill up? I'm not aware of a way to do it right now without handling logs in the container and avoiding the container's stdout/stderr.

This is a neat little optimization which can help you avoid needing to convert everything into utf-8 underneath the hood - leaving things in their raw/encoded forms. This may help in certain cases but would probably also make the C-api slightly more complex.

The real problem with Python2 is that it attempts to auto-decode bytes into unicode by guessing the encoding. This actually works most of the time, but not always. Unfortunately the fact that it works at all causes people to ship code that they think is fine... until later when a byte-string comes along with a non-standard encoding and it blows up. Python3 fixed this by making it blow up every time.

On the contrary, Objective-C is one of the only languages that actually gets header files right and subsequently they are a wonderful feature. They are very readable since it's now possible to write them to perfectly describe your public interface. All implementation details are kept in the .m where they should be.

CFFI works fine with CPython, and ctypes loads shared libraries without issue as well.

For hysterical reasons, pip has never supported binary eggs. Wheels are the replacement of the future!

While pip does not support binary eggs, easy_install still does. If you want binary distribution with pip you need to use wheels (as you are, of course).

As far as a REST API supporting etags and if-none-match headers, it's pretty unexpected that if I supply an if-none-match to the request, the server may keep the connection open for an arbitrary amount of time. I'd expect that behavior to be a side-channel of the normal 304 response. For example, it should only keep the connection open if I supply ?timeout=60 resource option or X-Modification-Timeout: 60 header.

Yes, totally. It is completely lacking any mechanism that allows collection-level operations. If you want to create a bunch of resources you have to abandon the supported headers and return a list of ETags in the body, removing any niceties the client would've given you for standard "REST" support. Same for the Content-Location that you mentioned.

I don't understand why the library chooses to require gevent. That's a large dependency for an API that might be useful otherwise. That should really be up to the user since it looks like it'd work fine in its own thread or standalone.

Yes but while implicit route ordering works a lot of the time, I'll gladly keep Pyramid's concept of explicit ordering, which is the main source of verbosity in the Pyramid setup which separates routes from views.

The ordering of your patterns matters, so that is done at config time. However it's very common to want to have unrelated code executed depending on the type of request to a URL. Pyramid will do this lookup for you, rather than polluting a gigantic view function with multiple code-paths for distinct functionality.

    @view_config(route_name='hello', request_method='GET')
    def get_hello(request):
        return Response('a GET request for %s' % request.matchdict['name'])

    @view_config(route_name='hello', request_method='POST')
    def post_hello(request):
        return Response('stored info')

    config = Configurator()
    config.add_route('hello', '/hello/{name}')
    config.scan()
    app = config.make_wsgi_app()