On 30 September 2015 at 01:31, Chris Barker - NOAA Federal <chris.bar...@noaa.gov> wrote: > It may be -- I've still have to test. Neither Windows nor py3 are my > primary production versions.
Part of the problem here is that people put up postings saying "do this" having checked that it works for them, and then others say "but it doesn't work", without giving any information as to why or providing any means to improve the instructions. I'm not suggesting here that you're going to do this - but those instructions are in essence the "official" (not well documented, conceded) advice at present, and they have been tested by a number of people for whom they work. They have also been reported to fail, but (as noted above) never in a way that allows us to improve them :-( They will remain the official advice, I suspect, until we get better feedback. > But the last time I tried the SDK approach was for py2.7 on Win64, and > it was both a pain, and impossible to set up to "just work" in my > highly secure environment. Well, I'd need more explanation of the issues. Was "install the SDK" a problem? Or was "set the environment variable DISTUTILS_USE_SDK"? Or did the instructions to do those two things not work? (I appreciate we're talking about 2 different things here, and I think Python 3 is a much less painful case than 2.7 on win64 was prior to the Visual C for Python 2.7 package). I suspect (from your mention of a highly secure environment) that installing the SDK was the main pain point. That's been the case for a number of people, I believe. But I don't think advice on how to install the Windows SDK in various environments is something we'd want to maintain in the Python documentation... This of course is another aspect of the problem - the official answer is "use a supported version of Windows, ensure you have the necessary permissions to install the needed software, and off you go". But in real life people want to build on an old laptop they had lying around, or on a VM they created on Linux, or on their Linux box using Wine, or on the box they use for a load of other development that has more SDKs than you want to imagine already installed, some of which got broken in the past, ... Or they need to use mingw, because a key library can't be compiled with Visual Studio. These are all real problems, and the people fighting them are doing a huge amount of good work building binary distributions for the community. They document what they are doing to solve their issues and those documents show up on Google, causing people who just want to build a simple extension to find them and get hopelessly confused. > So at best, it needs some serious documentation. And no, it shouldn't > be just a blog post somewhere (unless maybe Steve Dowers's blog). OK, without wishing to minimise what I fully agree is a serious problem, at a very high level the instructions are: For Python 2.7: 1. Install "Visual C++ Compiler Package for Python 2.7" 2. Use (a recent version of) setuptools in your setup.py (pip will do this for you, in any case). 3. Done. For Python 3.4 1. Install "Windows SDK for Windows 7 and .NET Framework 4" (v7.1) 2. Work from an SDK command prompt (with the environment variables set, and the SDK on PATH). 3. Set DISTUTILS_USE_SDK=1 4. Done. For Python 3.5 1. Install Visual Studio 2015 Community Edition (or any later version, when these are released). 2. Done. > Thus whole issue has been dogging python on windows for many years -- > it never has been easy to find out what to do. > > In fact, there are all sorts of Blog posts out there, with various > levels of out of date, conflicting, or just plain wrong advice. And this is why it's hard to fix the problem - people don't look at the documentation, they don't try to find "official" advice, they simply google and get a load of confusing advice. See above as to why some of those documents are there, and are more complex than the average user needs. > A definitive version in the official docs would be a very good thing. Well, I'd happily put the above instructions in the packaging user guide (packaging.python.org). Would that be sufficient for you? Paul _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
