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
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python