How to install Python package from source on Windows

[Chris Angelico]

On Fri, May 19, 2017 at 7:46 AM, bartc <bc at freeuk.com> wrote:
> On 18/05/2017 21:12, Chris Angelico wrote:
>>
>> On Fri, May 19, 2017 at 5:29 AM, bartc <bc at freeuk.com> wrote:
>
>
>> "largely" verified. Can you be absolutely certain that not one of
>> these compiler-detected issues is actually a problem? Would you stake
>> your life on it - for example, would you compile this code and put it
>> in charge of an airliner that you then ride on?
>
>
> No I wouldn't. But I wouldn't trust any C or C++ or Python code either!
>
> I want people who write such systems to use something like Ada, or a
> stricter, safer subset of one of those others. And add redundancy on top
> plus all the other things they do in aviation.
>
> But still not Python or other languages where you trap most errors at
> runtime rather than compile-time. Not even for the in-flight entertainment.

I have written HLL code that I would trust my life to. And while I've
never actually been in a position of doing so, I have certainly
gambled my livelihood and reputation on such. In fact, I do so every
day. Detecting bugs at compile time is valuable, but no compiler can
ever prove that a program is bug-free; a test suite is better, but
still imperfect. The bar for me to trust my life to a piece of
software is that it be comparable to the baseline chances of "out of
the blue" disaster. For instance, there is a slim chance that the
building you are in right now will collapse, crushing you to death. Or
that, while you're walking out in the open, a meteor will hit you on
the head (it can't be a meteorite yet, right?). Or that a headcrab
will teleport in and attack you, just when you don't have a crowbar
handy. They're all extremely low probabilities, but nonzero. Once the
chances of this program causing death are in that kind of range, I am
happy to trust my life to it.

Of course, it's often more complicated than that - there's an overall
*system*, not just a single program, and you can design things so that
an unexpected exception merely causes the program to restart. In that
case, the chances of a fatal disaster depend on the whole system
failing. But the principle is the same.

>> In other words, you are *DELIBERATELY* making your program
>> non-portable.
>
>
> That's true; it probably won't work on a obsolete system or a DSP or some
> oddball mainframe, but... so what?

Or even a modern computer that you just haven't happened to use. Check
out the supported platforms for virtually any large open source
project; now look at what systems your program will run on. You claim
that the simplicity of yours means it's more portable. I think the
facts are against you on this.

> And why am I being put through the third degree?
>
> Will every program /you/ write work on every computer in the world, past,
> present and future?

Past? No. Most of the programs I write depend on a particular compiler
or interpreter, and they have their requirements.

Present? Well, not *every*, but ideally they should run on all the
major platforms and as many as possible of the minors. In 2017, the
major platforms are Linux, Windows, and Mac OS; the minors are often
somewhat similar to one of the above (thanks largely to the POSIX
standards), and thus can be supported by... oh right, the configure
script that you hate so much.

Future? Probably. Hard to say, but there's very little reason to
believe that they won't.

> Would you trust every piece of software you write (ignore any irrelevance!)
> to control the systems in any airline that you ride on?

Every piece? No, but any piece about which I make the sorts of claims
you're making about yours, yes, I absolutely would.

> You're being entirely unfair. Someone creates a product that probably runs
> on 95% of the world's computers (the ones with a keyboard), and your
> criticism is that it doesn't work on the 5%. Or it probably has bugs in it
> so it can't be used to control a space shuttle.

A lot less than 95% of the world's computers have keyboards. If your
program depends on a keyboard, it's severely limited.

> I'm sorry, Mr Perfection, but that's the best I can do!

I'm not demanding perfection. I'm demanding that you live up to your boasts.

>> Why not just distribute a binary instead? You're not
>> gaining any portability.
>
>
> How do binaries work with Linux? Are they guaranteed to work across Linuxes
> running under the same processors as happens with Windows?

About the same as with Windows, actually. A binary depends on the CPU
architecture and a few other things. But how many actually-different
systems have you tried your code on?

>> I know that there are problems with C. But you don't eliminate them by
>> saying "I compile other code via C". Even with complete unit-test
>> coverage, you can't prove that your translator is 100% bug-free. And
>> how much test coverage *do* you have, bartc?
>
>
> Well, if something goes wrong, I usually know soon enough. My static
> language M is written my dynamic language Q. Q has a compiler and
> interpreter written in M. There is a circular dependency which is very
> sensitive to problems. (I used to have the Q compiler written in Q too.)

That's considered to be a fairly basic requirement. It's hardly a
great boast. More importantly: Can your compiler also be compiled with
multiple of the major compilers? That's how you verify something. (For
instance, you can build gcc using clang, to ensure that it is honestly
compiling itself, and not simply perpetuating a bug.)

https://en.wikipedia.org/wiki/Bootstrapping_(compilers)

> I also need to detect any such problems before I've been through a couple
> more generations, otherwise everything - including all my other tools - can
> suddenly stop working. (Then it's time to see if my backups work.)

Or, for the rest of the world, it's time to 'git bisect' and track
down the bug. (Or the equivalent in Mercurial or whatever other source
control system you use.)

> It seems a bit of a luxury that the CPython people can use an external tools
> (C language and compilers maintained by other people), and don't need to
> worry that a bug that has slipped past that has unknowingly infected gcc or
> MSVC in subtle ways.

Yes, and it's a great luxury that the CPython people don't also have
to build their own operating system, BIOS, and hardware. So? Everyone
uses external tools. What's your point?

ChrisA