How to install Python package from source on Windows

[bartc]

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.

> 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?

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?

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

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.

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

> 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?

> 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.)

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.)

For a change, M can emit C code. I can run my own C compiler (written in 
M) to create a new version of Q, which compiles a new version of M, 
which compiles a new version of the C compiler...

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.

-- 
bartc