Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed1a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Mon, 20 Jan 2014 03:30:57 +0200
From: =?utf-8?B?R8O2a3R1xJ8=?= Kayaalp <self@gkayaalp.com>
To: python-list@python.org
Subject: Re: Python program distribution - a source of constant friction
References: <CAAu18hfKcJQzvebFcooUO3eO3TSho-VodNODv0aTiCLjeRxGZw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <CAAu18hfKcJQzvebFcooUO3eO3TSho-VodNODv0aTiCLjeRxGZw@mail.gmail.com>
User-Agent: Mutt/1.5.22 (2013-10-16)
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.5732.1390174270.18130.python-list@python.org>
Lines: 120
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:64332

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 addre=
ss
> friction points that make it hard for a non-Python audience to use Python
> and applications developed in Python.
>=20
> Well, here is one.
>=20
> 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 installe=
d,
> Java applications work seamlessly.  I download them, execute them, and,
> unless they are very old and give themselves away by using a non-native s=
et
> of GUI widgets, I probably forget that I am running Java at all.
>=20
> 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 t=
he
> problem of distributing anything more complicated than a single-file
> program to end users.
>=20
> 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.
>=20
> 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, b=
ut
> 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=
!)
>=20
> There are tools that will package up binaries of python and create
> something that will even run without an interpreter installed on the targ=
et
> 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.
>=20
> 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 th=
ey
> 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 th=
an
> 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 a=
re
> needed?  But at any rate, I think that some more thought in this area wou=
ld
> be very useful.
>=20
> 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 a=
ll
> 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."
>=20
> 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."
>=20
> 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 n=
et
> for packaging things for a Python audience are extremely good.  Sending
> python code to other python developers is extremely easy.
>=20
> But it is not easy to send code to non-python developers.  The promise th=
at
> 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.
>=20
> IMHO, anyway.
>=20
> Nicholas

> --=20
> https://mail.python.org/mailman/listinfo/python-list


--=20
G=C3=B6ktu=C4=9F Kayaalp <self@gkayaalp.com>