Python 2 to 3 conversion - embrace the pain

[Cameron Simpson]

On 17Mar2015 05:30, Mario Figueiredo <marfig at gmail.com> wrote:
>On Tue, 17 Mar 2015 14:42:42 +1100, Ben Finney
><ben+python at benfinney.id.au> wrote:
>>Mario Figueiredo <marfig at gmail.com> writes:
>>> On Tue, 17 Mar 2015 09:02:38 +1100, Chris Angelico <rosuav at gmail.com>
>>> wrote:
>>> >Imagine you need a PostgreSQL database for your Python application -
>>> >which also means you need psycopg2, of course. How do you go about
>>> >writing installation instructions?
>>> >
>>> >* WINDOWS *
>>> >1) Install the latest Python 3 from https://www.python.org/downloads/windows/
>>> >2) Install the appropriate version of psycopg2 from
>>> >http://www.stickpeople.com/projects/python/win-psycopg/
>>> >3) Install the latest PostgreSQL from
>>> >http://www.postgresql.org/download/windows/
>>> >4) Install my program from blah blah blah
>>> >
>>>
>>> Are you saying this is a problem for any developer?
>>
>>Yes. They need to write installation instructions, and the more complex
>>those instructions are the fewer prospective users will bother.
>
>The prospective users in this context are software developers. If
>software developers can't understand instructions and can't be
>bothered following linear procedures, they cannot write good code.

"Linear procedures" often only look that way because the list is shortened, 
yea, even unto just headings.

There can be multiple ways to do each step, especially if one is juggling (or 
considering juggling) multiple versions. If one has to iterate then each of 
these steps can have internal loops and the whole process can require 
backtracking to redo things. Possible issues include around buggy releases of 
components, unfortunate decisions about the install regime, issues with the 
local dev environment (eg compile steps requiring unmentioned or special 
packages in the platform which may not be installed from the supplier), build 
options on/off, build tools requiring special (and ideally, badly or un- 
documented) config options (I am looking at you, RHEL lib64 stuff with 
autoconf).

I distribute an adzapping tool. It has two install modes, the default simple 
one and the optional more configurable one. The simple one reads:

  - make sure you have squid installed
  - install the script (a single perl script) somewhere on your system
  - add a single line to your squid config

One recurring request from some users is separation of the zapping patterns 
from the script; as shipped it is a single file with the patterns embedded. I 
have resisted this _because_ it would make installs _much_ harder for users.

Alternative anecdote: long ago when escaping from CVS to a newer VCS, I looked 
at SVN.  It was popular, etc. But the install/build chain was insane. Many 
prerequisite libraries, none available from the OS supplier, all needing 
special build/installs, and there were certainly buggy prerequisite library 
releases to be tripped over and avoided. A nightmare.

Not worth the bother. And I bothered for a long time trying to get it 
installed.

Compare Mercurial. Really easy, worked immediately, etc. Guess which I use.

IMO Mercurial is better anyway, but SVN shot itself in the foot with the 
install requirements.

I'm capable of following linear procedures. But I'm also capable of deciding 
that procedures are unreasonably complex, especially when they have bugs.

Cheers,
Cameron Simpson <cs at zip.com.au>

Wagner's music is better than it sounds.        - Mark Twain