TL;DR -- yes, documenting this in packaging.python.org would be great!
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.
Exactly. Which is why a Blog post is not the answer. If I find a blog post, I have no idea how well vetted and tested it is. If you look at the history of the Cython Wiki page about this, it becomes very clear how much confusion there is. (Though I think it's in pretty god shape now-- wikis have the advantage of being able to evolve and getter better).
I'm not suggesting here that you're going to do this -
Absolutely not -- I would not post anything anywhere without review -- this's kind of the point. If I find it in an official source, I know it's been reviewed.
us to improve them :-( They will remain the official advice, I suspect, until we get better feedback.
Which is my point -- how do I currently know what the official advise is? (Yes, I know now -- thanks!) But posting to python-dev is exactly the wrong way to find out!
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?
The issue was not having permissions to alter the registry the way we wanted. But again, I'll need to do some proper testing with up to date everything and see what happens.
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).
Good to know.
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...
Agreed -- if you can't install it you can't install it. And if it can't be installed in user-space, that's between MS and your sysadmins...
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".
Well, I for one think that's fine. Supporting open source software on a closed-source OS is going to have these pain points.
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.
That new MS installer is really really great.
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.
This, unfortunately is non-trivial, and really a pain if you want to automate builds. Apparently, conda-build has got this automated under the hood. Maybe that could be kludge do into setuptools?
- 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.
Well, yes, but when there is no official advice, looking for it doesn't help.... I, for one, have looked for docs and official advise over and over again for many years ( back when kept trying to remember if py2.6 was built with VS2003 or VS2008, or ??
Well, I'd happily put the above instructions in the packaging user guide (packaging.python.org). Would that be sufficient for you?
That would be great, thanks! An "official" source, but easier to update that the regular docs. Thanks, -Chris