[Distutils] self.introduce(distutils-sig)

[Steve Dower]

> From: Jim Fulton
> On Mon, Mar 18, 2013 at 12:34 PM, Steve Dower
> <Steve.Dower at microsoft.com> wrote:
> > I just joined up after the various discussions at PyCon and wanted to
> > say hi. (If you were also there and want to put a face/voice to the
> > name, I did the Visual Studio demo at one of the lightning talks.)
> 
> That was a very cool demo.

Thanks!

> > The main reason I want to get involved is the openly acknowledged lack
> > of Windows expertise that's available. I work at Microsoft and part of
> > my job description is to contribute
> > code/testing/time/documentation/help/etc. to CPython. (I can also do
> > testing/time/help for other projects, but copyrightable artifacts are
> > more complicated and, for now, not okay with our
> > lawyers.)
> >
> > I expect I'll mainly be lurking until I can be useful, which is why I
> > wanted to start with this post. I'm pretty good with Windows, and I
> > have direct access to all the experts and internal mailing lists. So
> > just shout out when something comes up and I'll be happy to clarify or
> research an answer.
> 
> At the packaging panel, an issue was raised regarding issues with 32-bit and
> 64-bit windows packages. I don't remember the details.  Were you there?
> If not, maybe someone can describe the issue here.

As I understand, the issue is the same as between different versions of Python and comes down to not being able to assume a compiler on Windows machines. It's easy to make a source file that will compile for any ABI and platform, but distributing binaries requires each one to be built separately. This doesn't have to be an onerous task - it can be scripted quite easily once you have all the required compilers - but it does take more effort than simply sharing a source file.

Another issue is the CPython installer itself is very biased towards only having one of 32/64 and not both, despite having 4 possible configurations (excluding virtualenv and xcopy installs). The default installer settings will try and put 32 and 64 in the same folder, which is easily solved, but the registration information also goes into the same location. On Windows Vista and later (possibly XP, but I'm not going to promise that) there is automatic redirection for 32/64 that separates it, so that an installer will find the right path, but the per-user installs don't get this and installing both 32 and 64-bit versions will simply overwrite each other.

As a result, it's hard for an MSI installer to find the right target version, and because it contains specific binaries finding the right version is essential. (I know so much about this because an IDE also has to find the versions, and there are simply some situations where it is impossible.)
 
> Also an idea, fwiw: it would be awesome if MS provided something like
> travis-ci that executed tests on windows for open-source projects hosted in
> github (and other places like bitbucket, which I prefer).
> Maybe projects would start sporting "Windows: passing" buttons. :)

Bitbucket is starting to get some love here, and we've been pushing to get Mercurial on equal standing with Git internally. Right now, our small Python team isn't influential enough to get a commitment to a testing service, but there's absolutely no reason why one can't be set up with Windows VMs on any of the cloud services out there (pip is already using AWS for this). Funding from the PSF may be easier than funding from MS, though I've never tried to get funding from the PSF before so I could be wrong :)


> Jim
> 
> --
> Jim Fulton
> http://www.linkedin.com/in/jimfulton
>