I'm quite concerned about this new tool. I'm sorry to say that, but it does not seems to match the code quality I expected.
So, I downloaded it from the Ryzom website and got an archive which contains 2 files : "Install Ryztart" which is a dynamically linked x86-64 executable which doesn't have the executable bit set and "package.bin" which is a shell script followed by a blob of data. No documentation of any kind, we are expected to guess what to do with those files. Since "package.bin" is the only file with the executable bit set, I try to start it :
Please note that, despite the critical failure, the soft doesn't exit. Instead, it stalls until you kill it.
Starting it without X installed has the self-update to fail, which is quite strange but still ok. However, the missing dependency on the Python humanize module is unacceptable: it fails even if the "python-humanize" package is installed on the system and therefore it looks like an issue with a virtualenv. Such failure makes me feel like this soft has never been tested before live deployment.
Before judging this soft too harshly because of this mistake, I had a look at the source code. Let's have a look at the start.sh script, which is 7 lines long and should be the first thing to start :
Line 1 (the shebang): not portable
Line 2 (define $REVISION): Why am I supposed to be in a git repository? Why am I even supposed to run git in order to play a game? Why is the number of commit considered as some king of software version? This is just all wrong.
Line 3 (sed) : Why does the program overrides a configuration file at each startup? Where the hell is this "data" directory where this configuration file is supposed to be since it's not in the git repository?
Line 4 (rsync) : Why using rsync to start a game? Why having such an external dependency (just like git)? By the way, where is the list of those external dependencies? What is this "../ryztart-dev/" directory supposed to be and when is it created and populated?
Line 5 : The only correct line since it's empty.
Line 6 (virtualenv) : So, here we activate a python virtualenv which has never been created…
Line 7 (python) : Using $* is quite dangerous, "$@" (with the double quotes) would be a much safer choice.
The sources are obviously not meant to be used by anyone else than Ryzom's devs. With absolutely zero documentation on how to use those sources to get the distributed executable, it's not that useful.
In fact, because the executable stalls instead of exiting, we can inspect what is happening : package.bin extracts some compressed files into a temporary directory (the path is visible on the error log). Theses files are:
Looking deeper into the dependencies only raises more concerns. One example is the way Python packages are installed :
By the way, you should have a look at the Python packaging user guide. Python packages are a mess to deploy correctly, this is the way to keep things as clean as possible.
I'm quite afraid to look further, I even found some compiled libraries (WTF???). I would really prefer that our subscription's money goes to actual Ryzom development instead of this absurd "installer". There is many bugs waiting to be solved and this "installer" will only add new ones AND prevent new players from joining the game.
Anyway, I won't use this "thing" and I would recommend that nobody else's does.
So, I downloaded it from the Ryzom website and got an archive which contains 2 files : "Install Ryztart" which is a dynamically linked x86-64 executable which doesn't have the executable bit set and "package.bin" which is a shell script followed by a blob of data. No documentation of any kind, we are expected to guess what to do with those files. Since "package.bin" is the only file with the executable bit set, I try to start it :
Please note that, despite the critical failure, the soft doesn't exit. Instead, it stalls until you kill it.
Starting it without X installed has the self-update to fail, which is quite strange but still ok. However, the missing dependency on the Python humanize module is unacceptable: it fails even if the "python-humanize" package is installed on the system and therefore it looks like an issue with a virtualenv. Such failure makes me feel like this soft has never been tested before live deployment.
Before judging this soft too harshly because of this mistake, I had a look at the source code. Let's have a look at the start.sh script, which is 7 lines long and should be the first thing to start :
#!/bin/bash
REVISION=$(git rev-list HEAD --count)
sed -i "s/version_minor = .*/version_minor = $REVISION/" data/app.ini
rsync -a --exclude build --exclude __pycache__ --exclude builds/RyZtart --exclude dist --exclude env --exclude .git --exclude app.ini --exclude t.py ../ryztart-dev/ .
source env/bin/activate
python -X pycache_prefix=cache ryztart.py $*
Line 1 (the shebang): not portable
Line 2 (define $REVISION): Why am I supposed to be in a git repository? Why am I even supposed to run git in order to play a game? Why is the number of commit considered as some king of software version? This is just all wrong.
Line 3 (sed) : Why does the program overrides a configuration file at each startup? Where the hell is this "data" directory where this configuration file is supposed to be since it's not in the git repository?
Line 4 (rsync) : Why using rsync to start a game? Why having such an external dependency (just like git)? By the way, where is the list of those external dependencies? What is this "../ryztart-dev/" directory supposed to be and when is it created and populated?
Line 5 : The only correct line since it's empty.
Line 6 (virtualenv) : So, here we activate a python virtualenv which has never been created…
Line 7 (python) : Using $* is quite dangerous, "$@" (with the double quotes) would be a much safer choice.
The sources are obviously not meant to be used by anyone else than Ryzom's devs. With absolutely zero documentation on how to use those sources to get the distributed executable, it's not that useful.
In fact, because the executable stalls instead of exiting, we can inspect what is happening : package.bin extracts some compressed files into a temporary directory (the path is visible on the error log). Theses files are:
- The "app" directory (visible in the sources) with all of its junk.
- A cache directory.
- A "python" directory which looks like a virtualenv.
- An executable shell script named "install" and visibly generated during the creation of the final executables. Note that its purpose is to start "ryztart.py", just like "start.sh" does but.
- Various files like logs, a shared library, a desktop entry and so on.
Looking deeper into the dependencies only raises more concerns. One example is the way Python packages are installed :
- Some are installed via pip (good).
- Some are manually downloaded from pypa (bad, pip is included by default with the Python binary installers since Pyhton 3.4).
- Some are downloaded from Ryzom's website (bad).
- Some are downloaded from Ulukyn's personal repository (very-bad).
By the way, you should have a look at the Python packaging user guide. Python packages are a mess to deploy correctly, this is the way to keep things as clean as possible.
I'm quite afraid to look further, I even found some compiled libraries (WTF???). I would really prefer that our subscription's money goes to actual Ryzom development instead of this absurd "installer". There is many bugs waiting to be solved and this "installer" will only add new ones AND prevent new players from joining the game.
Anyway, I won't use this "thing" and I would recommend that nobody else's does.
---
Markanjio di SegafredoAlkiane
Noble Gardien des Matis - Noble Matis Guardian
Fléau de l'Empire - Scourge of the Empire