Changed version output accordingly to now display "{version} ({branch} branch)" if branch information is available (which should be the case if installation was performed from git).
(cherry picked from commit a48b5de)
You can now define a lookup file explicitely mapping virtual version tags to branches via regular expressions and a reference commit from which the commit distance will be calculated.
Format of the file is
<branch-regex> <tag> <reference commit>
The file is processed from top to bottom, the first matching line wins. If <tag> or <reference commit> are left out, the lookup table does not apply to the matched branches and the regular versioneer resolution (via git describe) takes place.
Current configuration makes "master", "staging" and any branch starting with "fix/" make use the default behaviour, all other branches (so basically all development branches) are defined as "1.2.0-dev"
(cherry picked from commit 212f40c)
Changed version output accordingly to now display "{version} ({branch} branch)" if branch information is available (which should be the case if installation was performed from git).
You can now define a lookup file explicitely mapping virtual version tags to branches via regular expressions and a reference commit from which the commit distance will be calculated.
Format of the file is
<branch-regex> <tag> <reference commit>
The file is processed from top to bottom, the first matching line wins. If <tag> or <reference commit> are left out, the lookup table does not apply to the matched branches and the regular versioneer resolution (via git describe) takes place.
Current configuration makes "master", "staging" and any branch starting with "fix/" make use the default behaviour, all other branches (so basically all development branches) are defined as "1.2.0-dev"
setup.py tried to use babel imports before the necessary requirements
were fetched. Now only tries to import that stuff if
babel_{refresh|compile|new} is called instead of importing it
in the file header.
Also included is a translation for (informal) german.
New languages can be added with "python setup.py babel_new --locale=<language code>" which will create the corresponding .po file from the existing .pot file under "src/octoprint/translations/<language code>". Translations can be refreshed from strings in source with "python setup.py babel_refresh". Existing translations can be compiled into usable translation files (.mo for python and .js for Javascript) via "python setup.py babel_compile".
You'll need to install the development dependencies for all of this to work, just issue "pip install -r requirements-dev.txt"
Note: numbers are not yet correctly formatted for their respective locale (e.g. "2.5mm" instead of "2,5mm" in german).
4.0.1 is currently causing issues with OctoPrint, this is a quick fix for that until I have the opportunity to investigate this further.
Workaround for second issue in #544
