Appveyor script

[fgregg]

This appveyor script will

• built and test BTrees on windows for multiple versions of python and 32 and 64bit architectures
• on a tag, deploy window wheels to pypi

You will need to

1. setup appveyor for the BTrees repo: https://www.appveyor.com/docs
2. create an encrypted variable for "password=the_zope.wheelbuilder_password" and let me know what it is, I'll incorporate it into the script. https://www.appveyor.com/docs/build-configuration#secure-variables

[mgedmin]

Shouldn't that python setup.py be python setup.py bdist_wheel bdist_egg?

[fgregg]

It looks like some body is already building window eggs for BTree? https://pypi.python.org/pypi/BTrees

[tseaver]

It looks like some body is already building window wheels for BTree?

That would be the zope.wineggbuilder deployment, which is on the same hard-to-maintain machine as the zope.winbot deployment.

[mgedmin]

Note how existing wineggbuilder uploads lack support for Python 3.3, 3.4 and 3.5 (and also for wheels).

We'll probably want to disable wineggbuilder for BTrees as soon as Appveyor starts working. That can be done by specifying maxVersion in https://github.com/zopefoundation/zope.wineggbuilder/blob/master/rackspace.ini#L274

[mgedmin]

BTW the only other ZopeFoundation project that uses appveyor that I know of is zope.interface:
https://github.com/zopefoundation/zope.interface/blob/master/appveyor.yml

(It doesn't build wheels or upload them to PyPI -- at the moment.)

The approach to Python versions seems quite different than here. Any reason for that? Can we simplify the zope.interface appveyor.yml?

[mgedmin]

I'd completely forgotten that the old wineggbuilder used to upload both .exe and .egg files. Question for the audience: do we still need .exe installers?

My gut feeling is that people who still use zc.buildout will need .egg, and people who have migrated to pip will need .whl, but probably nobody needs .exe. Unless there are still people who install stuff manually by downloading installers from PyPI and running them?

[fgregg]

Do you need anything else from me right now?

[mgedmin]

Here's the encrypted zope.wheelbuilder password for Appveyor: RtpeKCle25vCixaUcJBu6Q==

Here's the appveyor project page, under my personal appveyor account: https://ci.appveyor.com/project/mgedmin/btrees

How does ZopeFoundation intend to manage appveyor accounts?

[mgedmin]

I don't know how to ask AppVeyor to try-build this PR.

I expect it will try a build when you push a commit to update the encrypted secret.

[fgregg]

Hi @mgedmin it looks like you have to do a kind of workaround for this http://help.appveyor.com/discussions/problems/2209-node-grunt-build-specify-a-project-or-solution-file-the-directory-does-not-contain-a-project-or-solution-file#comment_36945393

[mgedmin]

Why do you say that? The current appveyor failures are expected: none of the branches being built had an appveyor.yml.

Now we're waiting for you to push any commit (e.g. updating the encrypted secret) to this branch so Appveyor gets a chance.

[fgregg]

Woops! Sorry it's building. Appveyor disables deploys in Pull Requests, so that's why that section is no showing up.

[fgregg]

Okay, I think this good to merge. The failing build is due to real failures of the tests. #32

[mgedmin]

Let's get the broken test fixed (or at least skip it on 64-bit windows with @unittest.skipIf or something) before merging this.

[fgregg]

testing the sys.maxsize here, since this is the only PR with appveyor tests

[tseaver]

Heh, @mgedmin just turned off appveyor for branches w/o .appveyor.yml.

[tseaver]

@fgregg should I close #34?

[fgregg]

@tseaver sure, we can get it working in this branch.

[fgregg]

Okay the sys.maxsize idea won't work because

on windows python 3, x64

print(sys.maxsize) 
9223372036854775807

[tseaver]

Hmm, that is weird. I know the C code actually uses PY_LONG_LONG for keys and values, so I'm not even sure why the error occurs.

[tseaver]

For reference:

• BTrees.tests.common.LARGEST_64_BITS is 9223372036854775807
• BTrees.tests.common.SMALLEST_64_BITS is -9223372036854775808

and the code raising the OverflowError is not in BTrees C code: when it detects a too-large / too-small value, it raises ValueError.

[fgregg]

hi @tseaver I merged in #35 and it's not a fix, yet.

[fgregg]

@mgedmin @tseaver maybe this PR should be merged into a branch, so that you can get the benefit of testing on appveyor without me being a bottleneck?

[tseaver]

@fgregg I merged / rebased the non-reverted commits from your branch onto the fix-appveyor-build branch in this repo: see #36.

[tseaver]

@fgregg Closing in favor of my changes on top of yours in #36.