Skip to content

Get tests working on Windows, fix issue #11#13

Open
daybarr wants to merge 5 commits intobuildout:masterfrom
daybarr:windows-fixes
Open

Get tests working on Windows, fix issue #11#13
daybarr wants to merge 5 commits intobuildout:masterfrom
daybarr:windows-fixes

Conversation

@daybarr
Copy link

@daybarr daybarr commented Apr 24, 2017

This is another attempt at fixing #11 (replacing #12) that should also work for Linux builds.

cd635a9 and 502e3ad fix two issues that were preventing bin/test from working on Windows.

1f51489 is TDD - changes the case of the demo sample wheel to Demo so that issue #11 manifests when the tests are run on Windows, so we can test any fix.

343ce30 contains the actual fix. Here we avoid the problem by monkey patching setuptools (again - it was already done for other reasons). We now avoid the call to pkg_resources.normalize_path because on Windows that was lowercasing the path, which makes sense for comparison reasons if we are indeed comparing paths and they can come from different sources with different ideas of the cases used, but not if we're going to later use that path to extract important and case-sensitive information.

daybarr added 5 commits April 24, 2017 15:06
On Windows, zc.buildout.easy_install.scripts returns a 2 element list
containing py.exe and py-script.py
I think wheel.install.WheelFile isn't properly managing its handles and
doesn't close the zipfile when it's done with it. Force a gc at tearDown
time to clean up any references and so close the handle prior to the
rmtree done by buildoutTearDown which was failing on Windows with:

WindowsError: [Error 32] The process cannot access the file because it
is being used by another process:
'c:\\...\\_TEST_\\sample_eggs\\demo-1.0-py2-none-any.whl'

Also, can't use self.register_teardown because (bug?) buildoutTearDown
doesn't call the registerd functions in reverse order, so our cleanup
would run *after* the rmtree call regsitered by buildoutSetup, which is
too late.
Because this triggers issue #11 on Windows, so we can test that it's
fixed.
@leorochael
Copy link
Contributor

Hi @daybarr,

I think wheel.install.WheelFile isn't properly managing its handles and doesn't close the zipfile when it's done with it.

Have you considered opening a bug report with the wheel package?

@leorochael
Copy link
Contributor

By the way, thank you for looking into this @daybarr.

@daybarr
Copy link
Author

daybarr commented May 3, 2017

Have you considered opening a bug report with the wheel package?

It's on my to do list ;) but to be honest, is a lower priority now that I am unblocked and have something working. Hopefully will get back to it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants