first attempt at moving stuff. needs testing

[flying-sheep]

moved pretty much everything until python3 -m omnitool worked.

everything still in the main directory is (AFAIK) not imported by anything.

also there are still a few places assuming the working directory to be somewhere specific. that should be fixed like here

[flying-sheep]

hmm, to get cx_Freeze.Executable to run, maybe we can do something like Executable('run.py', ..., includes = ['omnitool']), with run.py simply containing:

from runpy import run_module
run_module('omnitool')

[Berserker66]

should work, but it's not gonna be as simple as that. As omnitool accepts command line arguments. While at it, one could consolidate all command line argument handling into a new module though, as so far they're spread out all over the place.

[Berserker66]

Well, currently it bugs out at:

Traceback (most recent call last):
  File "C:\Python34\lib\site-packages\cx_Freeze\initscripts\Console.py", line 27, in <module>
    exec(code, m.__dict__)
  File "omnitool\__main__.py", line 5, in <module>
SystemError: Parent module '' not loaded, cannot perform relative import

I have a feeling declaring omnitool as a module and using relative imports is going to create issues with freezing and multiprocessing. I tried that a while ago with a game of mine.

[flying-sheep]

As omnitool accepts command line arguments

runpy takes care of that, or do you mean something else?

I have a feeling declaring omnitool as a module and using relative imports is going to create issues with freezing and multiprocessing.

no, that would be silly. the stdlib uses relative imports and declaring omnitool as a module isn’t different from declaring modules in other ways. there must have been another issue in your game, or simply some way of configuring cx_freeze that we didn’t discover.

[Berserker66]

stdlib modules aren't frozen as launch scripts, they never need to work like that. - they are simply put wholesome into library.zip. Anyway, let's give it a try anyway and see if we can solve issues.

[flying-sheep]

Parent module '' not loaded, cannot perform relative import

well, that’s why i said to use runpy. what you did fails as would python omnitool/__main__.py: this way __main__ doesn’t know it’s part of a module and indeed omnitool isn’t loaded in sys.modules.

what happens internally if you do python -m omnitool or runpy.run_module('omnitool') is basically:

import sys
sys.modules['omnitool'] = __import__('omnitool')

__package__ = 'omnitool'

eval(open('omnitool/__main__.py').read())

but please let’s not do that, but simply use a runpy script (if possible)

[Berserker66]

Sure, go ahead and do that. I'm improving on the Updater thread, making it download tImages.zip if it doesn't exist and when I'm done I'll enjoy my birthday ;)

[flying-sheep]

will do!

:tada: happy birthday! :birthday:

[flying-sheep]

seems to work now! again, i didn’t test anything but starting it up, but it seems to shape up nicely!

[Berserker66]

I guess we drop python 3.3 due to pathlib. I'll likely not have time today to do a proper thorough test, so expect merging tomorrow, unless there are larger issues I find. Then I'll try setting up automatic cx-freezing with travis and appveyor. This should in theory append the windows setups and linux binaries to any release tag. Unfortunately appveyor setup is very hard for me, as I have no powershell experience, nor much experience with automated windows builds in general >.>.

[Berserker66]

please do another test on your linux, if that passes, I think we can merge into master and go from there. It all works on my windows at least.

[flying-sheep]

i now get

XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
      after 33 requests (33 known processed) with 0 events remaining.
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
python: xcb_io.c:274: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
[1]    15106 abort (core dumped)  python -m omnitool

[Berserker66]

multiprocessing.set_start_method("spawn") is the method that should fix that error. Maybe it has to be called after runpy, instead of before?

[flying-sheep]

oh, i just started it using python -m. with run_omnitool.py it works fine!