Re: Python program distribution - a source of constant friction
On Mon, Jan 06, 2014 at 11:39:13PM +, 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
Re: Python program distribution - a source of constant friction
On Tue, Jan 7, 2014 at 12:09 AM, Nicholas Cole nicholas.c...@gmail.com wrote: [SNIP] Even so, things like that are harder to create than they could be, or less prominently documented than one might have expected. Case in point: I have an application a friend/colleague of mine would like to look at. I've no idea if he is running Debian or Redhat or FreeBSD or a Mac. Assuming I've not used any C extensions, it is *possible* to create something that will run on all of the above without any fuss at his end. It just isn't nearly as easy as it could be, which must be a shame. Nicholas. In a spirit of trying to not only highlight problems, but start to solve them: https://pypi.python.org/pypi/ncdistribute/ Feedback is very welcome. Version 1 is a naive approach - it doesn't filter the included files at all, and will include all detected dependencies that are not part of the standard library. Best wishes, Nicholas -- https://mail.python.org/mailman/listinfo/python-list
Python program distribution - a source of constant friction
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
Re: Python program distribution - a source of constant friction
On Tue, Jan 7, 2014 at 10:39 AM, Nicholas Cole nicholas.c...@gmail.com wrote: 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). This is where OS-provided package managers really shine. It should be possible to type: $ sudo apt-get install shiny-cool-problem-solver and have it go and fetch Python, the magical library you need (matching to the binary architecture of the target platform), and your code, plop them all into the right places in the file system, and give you a new command shinycool that just happens to shebang into Python. Well and good. Trouble is... Windows isn't up there. And trying to maintain packages for lots of different platforms is a lot of work. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python program distribution - a source of constant friction
On Monday, 6 January 2014, Chris Angelico wrote: On Tue, Jan 7, 2014 at 10:39 AM, Nicholas Cole nicholas.c...@gmail.comjavascript:; wrote: 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). This is where OS-provided package managers really shine. It should be possible to type: $ sudo apt-get install shiny-cool-problem-solver and have it go and fetch Python, the magical library you need (matching to the binary architecture of the target platform), and your code, plop them all into the right places in the file system, and give you a new command shinycool that just happens to shebang into Python. Well and good. Trouble is... Windows isn't up there. And trying to maintain packages for lots of different platforms is a lot of work. Even providing packages for (unfamiliar?) Linux distributions is a lot of work - unless a distribution picks up responsibility for an application. For sending applications to end users, something they can just copy straight into a bin/ directory is a real winner. The python zip file format is really good for many things, and from the end-user point of view extremely low friction. Even so, things like that are harder to create than they could be, or less prominently documented than one might have expected. Case in point: I have an application a friend/colleague of mine would like to look at. I've no idea if he is running Debian or Redhat or FreeBSD or a Mac. Assuming I've not used any C extensions, it is *possible* to create something that will run on all of the above without any fuss at his end. It just isn't nearly as easy as it could be, which must be a shame. Nicholas. -- https://mail.python.org/mailman/listinfo/python-list
