[Twisted-Python] Python3 twistd daemon for Ubuntu 14.04 alternatives

[Phil Mayers]

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