* py_modules parameter to setup() isn't documented in the setuptools
docs, but is in a general 'python packaging' one.
* So now the main scripts are NOT within the `eddn` package..
* But all other code is...
* But the schema files don't need to be.
# Conflicts:
# src/schemas/fssbodysignals-README.md
# src/schemas/fssbodysignals-v1.0.json
# src/schemas/fsssignaldiscovered-README.md
# src/schemas/fsssignaldiscovered-v1.0.json
With `import eddn.core.Validator` and the like it was actually picking
up the egg versions of the files, not local ones.
Currently this will run as per:
cd src/eddn
python Gateway.py --config ~/.local/share/eddn/dev/config.json
# Conflicts:
# src/eddn/schemas/fssbodysignals-README.md
# src/eddn/schemas/fssbodysignals-v1.0.json
# src/eddn/schemas/fsssignaldiscovered-README.md
# src/eddn/schemas/fsssignaldiscovered-v1.0.json
* Move the service scripts out of src/eddn/ into src/
* Move the schemas/ to src/schemas/
* Some updates to setup.py, i.e. source of files, but the setuptools
part isn't yet work.
# Conflicts:
# src/schemas/fssbodysignals-README.md
# src/schemas/fssbodysignals-v1.0.json
# src/schemas/fsssignaldiscovered-README.md
# src/schemas/fsssignaldiscovered-v1.0.json
The whole build/install process is dependent on the EDDN_ENV value
anyway, so we might as well use it.
This way if a future setup doesn't have a specific string in CWD this
check doesn't break.
Yes, this whole check means you MUST be building from a git checkout,
not the files sourced by some other means.
In Python 2.7 shutil.copytree() *always* preserves the file mode. I
don't want to rely on changing them in the source as that's fragile.
So, write our own recursive function to fix them after the copy.
Once we move to Python 3 we can use the copy_function argument, combined
with the umask we already set.
* Have 'dev' and 'live' components to many paths and file names.
* Have separate dev/live systemd start script configs.
* Have the systemd start script take a dev/live second argument.
* Try to ensure permissions on 'web' files by explicitly setting umask.
* 'monitor' files are for the web page showing status/stats.
* 'schema' files are a publically available copy of the schemas in-use.
* 'systemd' files are the start-<service> script and its config file.
