Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
Date: Mon, 6 Jan 2014 23:39:13 +0000
Subject: Python program distribution - a source of constant friction
From: Nicholas Cole <nicholas.cole@gmail.com>
To: Python <python-list@python.org>
Content-Type: multipart/alternative; boundary=089e0163576e6a380404ef55c4c2
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.5094.1389051596.18130.python-list@python.org>
Lines: 181
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:63376

--089e0163576e6a380404ef55c4c2
Content-Type: text/plain; charset=ISO-8859-1

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

--089e0163576e6a380404ef55c4c2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This email is inspired by a YouTube video of a talk that Jessica McKellar r=
ecently gave. =A0I was struck by her analysis that it is hard to remain a p=
opular 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 a=
nd applications developed in Python.<div>
<br></div><div>Well, here is one.</div><div><br></div><div>All of the early=
 books one reads on Python compare it to Java or similar languages. =A0Writ=
e code once, is the promise, and as long as your target computer has a Pyth=
on interpreter, your code will run. =A0For Java, I have to say! this really=
 does seem true. =A0Once I have a Java environment installed, Java applicat=
ions work seamlessly. =A0I download them, execute them, and, unless they ar=
e very old and give themselves away by using a non-native set of GUI widget=
s, I probably forget that I am running Java at all.</div>
<div><br></div>But as we all know, Python=A0isn&#39;t that simple. =A0I&#39=
;m not talking about the problems of cross-platform GUIs or other such thin=
gs. =A0I&#39;m taking about the problem of distributing anything more compl=
icated than a single-file program to end users.<br>
<div><br></div>I realise that I&#39;m not really, either, taking about the =
much written about=A0Python packaging problem. =A0I was going to berate the=
 packaging documentation for not really helping with the problem I have in =
mind, but I realised that=A0actually the kinds of packages that the Packagi=
ng Guide=A0is taking about are the kinds of things that developers and pyth=
on-proficient system administrators will be installing.<div>
<br></div><div>But what about the end-user? =A0The end-user who just wants =
a blob (he doesn&#39;t care about what language it is in - he just wants to=
 solve the problem at hand with your shiny, cool, problem-solving applicati=
on). =A0He is hopefully using a system on which Python comes as default. =
=A0At most one might get him to install a new Python interpreter and standa=
rd library, but asking him to do more than that is simply asking more than =
he will do. =A0Will your code run or not? (i.e. without him having to learn=
 what pip is!)</div>
<div><br></div>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. =A0If only they were better documented, less fragile and wo=
rked consistently with Python 3! =A0Even then, I&#39;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&#39;=
t need to maintain development environments for every possible target platf=
orm to get code to run.<div>
<br></div><div>What would be nice is something much less complicated. =A0So=
mething , for example,=A0that just takes everything except the python inter=
preter from a virtual environment, packs it up and turns it into a zip arch=
ive that really will run on a user&#39;s python installation without any ad=
ditional steps.=A0 There are a couple of tools to do something close to thi=
s, 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 m=
ore than a little experimentation to get right. =A0No doubt even here some =
extra glue or magic would be useful - what is the right thing to do when C =
modules are needed? =A0But at any rate, I think that some more thought in t=
his area would be very useful.=A0</div>
<div><br></div><div>And what about WSGI apps? =A0I regard WSGI as one of th=
e great features of modern Python. =A0But again, end users don&#39;t really=
 want to have to learn all about python and proxy servers running in front =
of special WSGI servers. =A0Most are not going to serve hundreds of thousan=
ds of users, but probably do need a little more than one connection at a ti=
me. =A0Even if the right solution is to create these complicated setups, I =
defy anyone to find me a page I could point a competent system administrato=
r (but non-Python developer)=A0at and say, &quot;here is my code, install i=
t in this directory and set up a webserver according to the instructions on=
 this single web page and everything will just work.&quot;</div>
<div><br></div><div>We are even further away from saying, &quot;Here is a s=
pecial zip file. Make sure you have a Python 3 interpreter ready and then j=
ust treat this file as you would any other service on your system. =A0Have =
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=A0with a r=
easonable level of security and reliability. =A0Of course, if you end up wi=
th more than a few hundred users, you will need something more specialised.=
&quot;</div>
<div><br></div><div>Python *packaging* looks as if it is getting sorted out=
. =A0Pip is going to be part of Python 3.4 and PyPI works very well. The in=
structions on the net for packaging things for a Python audience are extrem=
ely good. =A0Sending python code to other python developers is extremely ea=
sy.</div>
<div><br></div><div>But it is not easy to send code to non-python developer=
s. =A0The promise that you can just get your users to install a Python inte=
rpreter and then give them code to run on it is a worthy dream. =A0Perhaps =
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.</d=
iv>
<div><br></div><div>IMHO, anyway.=A0</div><div><br></div><div>Nicholas</div=
>

--089e0163576e6a380404ef55c4c2--