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 <s...@gkayaalp.com> -- https://mail.python.org/mailman/listinfo/python-list
