[Python-Dev] VS 2010 compiler

[Chris Barker]

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:
  - not a big deal there, though it's still hard to figure out what is the
"right" way to do it -- adding this to the packaging docs will help, I hope.

2) developers on other platforms that want to be able to build and
distribute their package for Windows users.
  - this is a semi-big deal for them -- they need to learn a bit about how
Windows works, and will find that annoying and frustrating because "why
can't this be as easy as Linux?" (or really "the same as Linux") ;-)

3) 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.
  - these are the hardest people to support -- they may know very, very
little about Windows command lines and environment variables etc.

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