Python program distribution - a source of constant friction

[Nicholas Cole]

This email is inspired by a YouTube video of a talk that Jessica McKellar
recently gave.  I was struck by her analysis that it is hard to remain a
popular language (as Python currently is) and her call to action to address
friction points that make it hard for a non-Python audience to use Python
and applications developed in Python.

Well, here is one.

All of the early books one reads on Python compare it to Java or similar
languages.  Write code once, is the promise, and as long as your target
computer has a Python interpreter, your code will run.  For Java, I have to
say! this really does seem true.  Once I have a Java environment installed,
Java applications work seamlessly.  I download them, execute them, and,
unless they are very old and give themselves away by using a non-native set
of GUI widgets, I probably forget that I am running Java at all.

But as we all know, Python isn't that simple.  I'm not talking about the
problems of cross-platform GUIs or other such things.  I'm taking about the
problem of distributing anything more complicated than a single-file
program to end users.

I realise that I'm not really, either, taking about the much written
about Python packaging problem.  I was going to berate the packaging
documentation for not really helping with the problem I have in mind, but I
realised that actually the kinds of packages that the Packaging Guide is
taking about are the kinds of things that developers and python-proficient
system administrators will be installing.

But what about the end-user?  The end-user who just wants a blob (he
doesn't care about what language it is in - he just wants to solve the
problem at hand with your shiny, cool, problem-solving application).  He is
hopefully using a system on which Python comes as default.  At most one
might get him to install a new Python interpreter and standard library, but
asking him to do more than that is simply asking more than he will do.
 Will your code run or not? (i.e. without him having to learn what pip is!)

There are tools that will package up binaries of python and create
something that will even run without an interpreter installed on the target
system.  If only they were better documented, less fragile and worked
consistently with Python 3!  Even then, I'm not sure this is the answer -
anything like that is bound to be a bit fragile and break one of the
attractive features of Python - that all things being equal, I don't need
to maintain development environments for every possible target platform to
get code to run.

What would be nice is something much less complicated.  Something , for
example, that just takes everything except the python interpreter from a
virtual environment, packs it up and turns it into a zip archive that
really will run on a user's python installation without any additional
steps.  There are a couple of tools to do something close to this, but they
are hardly well signposted in the python documentation (in fact I only
found them with the help of this list), and even these tools need more than
a little experimentation to get right.  No doubt even here some extra glue
or magic would be useful - what is the right thing to do when C modules are
needed?  But at any rate, I think that some more thought in this area would
be very useful.

And what about WSGI apps?  I regard WSGI as one of the great features of
modern Python.  But again, end users don't really want to have to learn all
about python and proxy servers running in front of special WSGI servers.
 Most are not going to serve hundreds of thousands of users, but probably
do need a little more than one connection at a time.  Even if the right
solution is to create these complicated setups, I defy anyone to find me a
page I could point a competent system administrator (but non-Python
developer) at and say, "here is my code, install it in this directory and
set up a webserver according to the instructions on this single web page
and everything will just work."

We are even further away from saying, "Here is a special zip file. Make
sure you have a Python 3 interpreter ready and then just treat this file as
you would any other service on your system.  Have it started by whatever
daemon manages services on your server, and it will all just work and be
able to handle a reasonable number of users with a reasonable level of
security and reliability.  Of course, if you end up with more than a few
hundred users, you will need something more specialised."

Python *packaging* looks as if it is getting sorted out.  Pip is going to
be part of Python 3.4 and PyPI works very well. The instructions on the net
for packaging things for a Python audience are extremely good.  Sending
python code to other python developers is extremely easy.

But it is not easy to send code to non-python developers.  The promise that
you can just get your users to install a Python interpreter and then give
them code to run on it is a worthy dream.  Perhaps all the pieces to do
this all seamlessly exist already, but if so they need much better
documentation, somewhere that it is really easy to find it.

IMHO, anyway.

Nicholas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20140106/98e49cfc/attachment.html>