[Python-Dev] VS 2010 compiler (original) (raw)

Chris Barker chris.barker at noaa.gov
Thu Oct 1 19🔞04 CEST 2015

On Wed, Sep 30, 2015 at 12:15 PM, Paul Moore <p.f.moore at gmail.com> wrote:

> This, unfortunately is non-trivial, and really a pain if you want to > automate builds.

Please clarify.

First point -- that was intended to be a lament, not a criticism. And certainly not a criticism of anything Python devs are doing / have done. It's more difficult than it "should" be because of how MS distributes and configures the compiler and SDK, and that they are no longer distributing the same thing they used to distribute (i.e. VS2010 Express).

I'm not at all sure that there is anything we can do to help....

But once upon a time, it really was as simple as:

  1. Install this freely available compiler from MS
  2. $ python setup.py build

and that is the case now with py2.7 and (I assume) py3.5

Compared to that, setting environment variables, having to use a particular command prompt, etc. is non trivial.

Part of the problem is that there are multiple audiences here:

  1. experienced Windows devs that are writing and building their own packages:
  1. developers on other platforms that want to be able to build and distribute their package for Windows users.
  1. users that want to be able to "pip install", and find that there is no binary wheel available, and they get the dreaded "can't find vcvarsall.bat" message.
  1. users that are not particularly familiar with command lines or development tools, but need a little C extension -- Cython, in particular, makes it really easy to do that -- but then you need to buld the darn thing. distutils (setuptools) makes it possible to do that with very, very little understanding of build tools, but you have to get set up first...

The whole process (including finding these instructions) is non-trivial for everyone of these use cases other than (1)[1].

What is non-trivial? Installing the SDK? I know, but

we said that's out of scope. Using an SDK command prompt? It is, sort of, particularly if (like me) you use powershell.

or gitBash :-)

But again, not our issue. I assume setting the environment variable isn't an issue - you can do it for the session rather than globally, so even restrictive permissions aren't a problem.

but both of these add steps to the "$python setup.py install" -- that really des make a difference to many users (see above)

I but it

is an acknowledgement that often the audience for this sort of instruction are stumped by Microsoft's less than intuitive install processes...

yup !

For context, installing mingw is just as messy, complicated and error prone (I speak from experience :-))

God yes!

so it's unfair to complain that the above is a non-trivial pain. I know of no install option that's less straightforward than this (except of course for "install any version of Visual Studio 2010, even the free ones" - if you have access to those, use them!)

exactly! but that is the standard I'm comparing against.

When it comes to usability, there really is no argument about whether something is "easy to use" -- As we've discussed, this comes up over an over again on StackOverflow, various mailing lists, assorted Blogs, -- there really is no debate about this being "easy".

What can be done about it is a different question. My argument is that docs can help, and maybe once this is in the packaging docs, all those mailing list questions can be answered with a link to that.

For automation, why not use Appveyor? See https://packaging.python.org/en/latest/appveyor/

yup -- very cool, I've been meaning to get that set up for distributing some stuff.

Unless you meant setting up a local build machine.

Exactly -- you need that while developing, anyway. And at the moment, I have a non-sophisticated user-base that needs to be working with a frequently updated gitHub repo -- so needs to build themselves.

(OK, if I had Appveyor doing updated binary packages every push, they wouldn't need to build themselves -- maybe someday)

If you want a simple "install a Python build environment" process, you could look at https://github.com/pfmoore/pybuild -

nice! I'll checdk that out. But I"m confused -- right in there, you write:

"setting up a Windows build environment can be a significant challenge"

then you ask me what is "non trivial" :-)

I haven't used it in a while (as

it's of no relevance to me, because I have VS2010) but it does work. I never publicised or distributed it, because I got too much pushback in terms of "but it doesn't work right on my system" (typically because the system in question usually wasn't a clean build of Windows) that I didn't have time or energy to address. But if it works for you, go for it.

I'll give it a shot, thanks!

I'll push an addition to packaging.python.org, probably tomorrow.

I'll look at that, too -- thanks much for your attention to this.

-CHB

[1] Actually, I've had some of the larger struggles with folks that ARE experienced Windows devs -- they tend to think "I know how to use Visual Studio; I know how to build libs", and then they try to go off and do it by hand, and/or with their favorite verson of the compiler... I've had to pound it home again and again that you REALLY DO want to use distutils (or setuptools) and the version of VS that Python was compiled with. :-)

--

Christopher Barker, Ph.D. Oceanographer

Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker at noaa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20151001/1f3bbf34/attachment.html>

More information about the Python-Dev mailing list