Python program distribution - a source of constant friction

[Göktuğ Kayaalp]

On Mon, Jan 06, 2014 at 11:39:13PM +0000, Nicholas Cole wrote:
> This email is inspired by a YouTube video of a talk that Jessica McKellar

Could you please share the link to the video please?

> 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

> -- 
> https://mail.python.org/mailman/listinfo/python-list


-- 
Göktuğ Kayaalp <self at gkayaalp.com>