Replace Pywin32

[Doadin]

After the issues with appveyor and pip and windows, I was looking over the code that needs pywin32 and noticed at least form a quick glance, most if not all code that uses pywin32 in deluge can be replaced by ctypes. more specifically:

ctypes.windll.kernel32.CreateMutexA

and

ctypes.windll.kernel32.SetConsoleCtrlHandler?

the mutex code does seem like it would be a bit more code a sample can be seen here:

​http://code.activestate.com/recipes/577794-win32-named-mutex-class-for-system-wide-mutex/

However just those two can replace 90% of the need of pywin32. And im sure the last 10% can be done as well I just havn't looked that much yet. Is there a reason not to change? Im sure pywin32 does just about the same thing and normally not trying to recreate something that is already done would be a good idea however I think our use uses so little of the module as a whole that in this case it would be worth it.

[Doadin]

the last 10% I mentions is where deluge handels hidden files and that falls under:

ctypes.windll.kernel32.SetFileAttributesW

and

ctypes.windll.kernel32.GetFileAttributesW

[Cas]

Yes there is a pywin32 unwanted install issue with pip on Linux and nuances with Tox platform config but we can workaround these until it's fixed. I don't see the benefit to switching from it. There are no other issues with pywin32, it's easy to use and switching has the potential to create more issues.

If we were to change I would rather we use cffi than ctypes and there is this project ​https://github.com/opalmer/pywincffi

Twisted want to move away from it ​https://twistedmatrix.com/trac/ticket/7477 however the list of reasons have been solved in the interim: ​https://pypi.org/project/pywin32/#files

For reference the pipenv issue: ​https://github.com/mhammond/pywin32/issues/1177

[Doadin]

the idea came from the issues with pip but not the reason for. the reason why I think it would be a good idea to move away is the fact that I think the code difference after switching to ctypes would make the overall code size in deluge smaller. we use so very little of pywin32 the replacement ctypes code even if we did have to add more would still be less. I have the same feeling for pygame. yes we might have to add more code to deluge but it out weighs the reduction in deps. In the case of pygame I think its even worse. If I remember right we depend on pygame solely to play a sound and only in the notification plugin. That seems like a big waste to me. the core idea behind a pywin32 and pygame change is more to reduce not replace.

[Doadin]

for example pymedia could do the same as pygame but the code for pygame is 3mb big pymedia is only 1mb. now pymedia is pretty old and hasnt been updated in a while so I dont think thats a solution but theres several alternatives pygame just like theres alternatives to ctypes. I think we should find better alternatives to both.

[Cas]

What is the actual size of the pywin32 files in the installer? That is what matters. For pygame it is quite a sizable amount but the pywin32 library files don't take up that much space iirc when compressed.

Maintainability will trump the size of the installer package. We have to bundle pygtk so a few extra MB is not such a big deal.

[Cas]

I think this needs revisited, it's not installable under msys2 for GTK3 so it's a bit of a PITA package. I think I have managed to resolve most of the issues and will make a future pull request.

[Cas]

The version stamping code in bbfreeze script will need a bit of work but could use pefile:

• ​https://github.com/erocarrera/pefile
• ​http://blog.dkbza.org/2007/02/pefile-parsing-version-information-from.html

For the disk space psutil is also not an option on msys2:

• ​https://github.com/giampaolo/psutil/pull/845

Essentially do everything with ctypes or pywincffi

However there is a major issue with the fact that twisted still requires pywin32 so even if we drop support that is still going to bite us! This also puts a spanner in using msys2 packages and creating a GTK3 windows build. Arrgghh!