On Tue, Mar 17, 2015 at 3:27 AM, Chris Barker
someone who has little knowledge of Python's internals, and just wants to build the latest version (either from hg or from a source tarball).
That's the assumption I'm following -- the user wants the latest version -- so probably already has easy access to an older version with which to run the build tools...
The tricky part here is defining the oldest supported version. "To build Python X.Y, you must already have Python ??? or later installed" - how do you pick the minimum? The older that minimum, the more warped the build code has to be (especially if you want to support 2.x as well as 3.x - imagine trying to make it possible to use the system Python on RHEL, as well as any 3.[1-4]), but go too far the other way and you end up with a multi-step build process ("first build Python 3.4, then use that to build Python 3.7") which is just going to be a pain.
But in the second case, it'd be much safer to minimize the requirements. If you can untar the source and just "./configure; make; sudo make install" your way to having the latest Python, that's a LOT easier than I've just been doing trying to get my Dad onto a newer Mozilla Thunderbird. (I don't understand what it's doing all along there, but it pulls a whole bunch of separate repositories when I say update, and there's a separate bootstrap step, and ... I dunno.)
requiring _some_, not very recent, python is not exactly
"""a whole bunch of separate repositories when I say update, and there's a separate bootstrap step"""
If there is an already build python (like OS-X, any general purpose linux distro, Windows if you don't mind point and clicking the python.org installer, etc, then it's not really a "bootstrap".
No, that's not what I'm talking about. I'm talking about trying to build Thunderbird and having to do a bunch of steps where I run this program, then run that, then let it chug its way through stuff, and then eventually it'll start building. Without detailed knowledge of the build internals I have no way of knowing what steps I can skip, so every time I want to test the build again, I have to go through them all. It took three parts of forever to figure out what was going on. I much prefer projects that ship with the standard "./configure; make" pattern. I don't care if the configure script is built by some arcane incantation, as long as it's checked into source control (or at very least is in the downloadable source tarball for any particular version). If I want to build your program, I don't want to have to hunt down your notes file, read it through in detail, and jump through a dozen hoops; I just want to point my compiler at your source, and then go make myself a hot chocolate while it does its work. ChrisA