On 22/02/17 17:42, Hynek Schlawack wrote:
I have to disagree here: I don’t want build tools of any kind in my final containers therefore I build my artifacts separately no matter what language. Of course you can just build the venv on your build
Agreed, 100%. Apologies if I gave you the impression I was advocating otherwise.
server without wheeling up a temporary container and then package it using Docker or DEB or whatever. You should be separating building and running anyway so Python – as much as I’d like Go-style single binaries too – is in no way special here. The nice thing about temporary containers though is that I can do all of that on my Mac.
I agree that you need to separate building and installation, and I've got no particular beef with using a container, chroot, throwaway VM or whatever works for people in doing the build phase. (What people do with the resultant build output - and in particular whether there is a lot of ignoring of the hard-learned lessons of system package managers going on now - I will not comment on ;o) What I was trying to say - badly, apparently - was that the system python *could* be attractive to someone because many dependencies may exist in the OS package list in suitable form, but conversely may not exist in PyPI in binary form for Linux. As a very simple example: if you have a traditional (non-container) Linux system hosting a Python application in a virtualenv, and you deploy a Python app to a virtualenv e.g. using Puppet or Ansible, you either need to: 1. Use no C extensions 2. Hope there's a manylinux1 binary wheel 3. Use the OS package and --system-site-packages 4. Compile the C extensions and make them available to pip #2 seems useful now that I know about it but - correct me if I'm wrong - the manylinux1 permitted C dependencies are super-tiny, and would not permit e.g. cryptography or psycopg2? #4 is what you are advocating for I believe? But can we agree that for smaller projects, that might seem like a lot of repeated work if the package is already available in the OS repos? Wondering out loud, I guess it would be possible for OS-compiled python extensions to be somehow virtualenv or relocation-compatible. One could envisage something like: virtualenv t . t/bin/activate pip syspkg-install python-psycopg2 ...and this going off and grabbing the OS-provided dependency of that name, extracting it, and deploying it into the virtualenv, rather than the system Python. There are doubtless all sorts of reasons that is not practical. Anyway, to be clear - I'm not advocating using the system Python. I'm trying to explain why, based on the efforts we expend locally, it could seem attractive to smaller sites. Cheers, Phil