Move code to python - starting with configuration

[royfalk]

Use boost python to get a C++ struct/class from python.
Implement Graphics2Config (temp name) - has resolution and screen number. Populate struct from config.json via C++.
Modify game to take resolution and screen values from config.yaml. Deprecates settings app.
Implement unit tests in configuration.

Code Changes:

• Have the PR Validation Tests been run? See https://github.com/vegastrike/Vega-Strike-Engine-Source/wiki/Pull-Request-Validation No. Minimal tests to see game works and resolution changes. Most testing done in unit tests.
• This is a documentation change only

Issues:

• Python code should be placed somewhere logical. My vote is /python.
• Lower resolution causes game to go out of bounds. Already noted by Evert.
• Need to complement this with a PR to assets.
• Need to complement this with a PR to assets for WC.

[evertvorster]

While I agree that the configuration part of Vega Strike needs work, I have a concern about including a Python package as part of the game.

While it is easier for software developers to just add Python stuff everywhere, it is a nightmare for packagers in distrobutions to resolve conflicts.

In my opinion it would be better to have pyyaml as a dependency of Vega Strike, and let the system provide the package.

On my system, pyyaml is already installed, and required by the following packages:

Required By     : beets  bottles  breezy  conan  picard  python-confuse  python-pytorch-opt-cuda
Optional For    : extra-cmake-modules  libinput  python-markdown  python-numba

If it becomes part of Vega Strike, I would have to strip it out as part of the install process to enable Vega Strike to co-exist with the above mentioned packages.

Arch specifically does not allow pip to run as pacman manages the Python packages installed in the system.

[royfalk]

Arch specifically does not allow pip to run as pacman manages the Python packages installed in the system.

So, I'm not real good with the whole dev-ops side of things. You raise some excellent points and I think that if we do support auto-install of python packages, it'll have to be as part of the install script. @BenjamenMeyer worked on these and I saw some apt-get directives there. I'll edit the above to say consider instead and let's see what Benjamen says.

[BenjamenMeyer]

@evertvorster would us trying to figure out how to use a Python Virtual Environment help?

Generally, we don't have much access to the system Python installation or packages. It would be nice to be able to use some other packages too. A Python Virtual Env might be a good way to go - let's us more specifically control the environment and reduces the potential for incompatibility with the system. Not sure how easy it is to do with Boost::Python though.

[BenjamenMeyer]

Not sure about reading the config in Python... it'd probably be better to read it in C++ land and expose some methods to update and save it to the Python world.

If we wanted to keep the YAML format (more below) then this would also remove the Python dependency; we'd just have to figure out how to do a C++ version (preferably easily integrated with Boost).

That said, we're already using JSON. We should probably be consistent with the file formats we're using and not use different ones all over. So it's probably wise to keep it to JSON.

All said - I do like the transition. Though to deprecate vssettings we would have to make sure all those settings get migrated over to the GUI.

[BenjamenMeyer]

while YAML is a little easier to read; it's not built-in to Python so requires an additional package.
We're already using JSON elsewhere and JSON is built-in to Python. It might be wiser to be consistent with ourselves and just use what's built-in. The code below barely changes; the file format does a bit.

YAML is a little nicer looking; but for the moment ...not sure if it's the right solution.

[BenjamenMeyer]

https://github.com/jbeder/yaml-cpp looks promising...but they removed their Boost dependency.
Boost currently lists YAML as a future development.

[royfalk]

I'm at a loss here. I have no idea why it's failing, except that it's all basically the same version.
Ubuntu Focal is based on Debian Bullseye/sid and Linux mint 20 is based on Focal.

[royfalk]

OK. Found it. It seems newer systems can do this on their own or something.

/usr/bin/ld: CMakeFiles/vegastrike_python.dir/src/python/config/python_utils.cpp.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I'll try and figure this out on my own tomorrow.

[royfalk]

Yesss!!! Finally.
@BenjamenMeyer please review.