Re-architect the code to make running from source simple

[Athanasius]

Currently the code only runs cleanly when it has been python setup.py installd into an egg.

Assume you have not done the egg install. If you're in the root of the source tree, such that, e.g. the Gateway code is in src/eddn/Gateway.py then:

1. .../src/eddn is what gets added to sys.path.
2. from eddn.conf.Settings import Settings will fail because eddn is on the end of that sys.path component, so this would need to be from conf.Settings import Settings.
3. If you start from src/ instead and thus use eddn/Gateway.,py to run it then sys.path contains the same and you have the same issue.
4. If you start from src/eddn instead and thus use Gateway.py then, again, sys.path has .../src/eddn in it and can't find any import beginning from eddn..

If you install the egg then this is masked because it will find eddn.conf.Settings in the egg. But now if you make any edits to the source files, and don't re-install the egg, you'll be confused as to why your edit apparrently did nothing. Your updated src/eddn/Gateway.py will be used, because you're literally specifying it on the commandline, but anything it imports will only come from the last installed egg.

---

This is just needlessly frustrating when trying to rapidly iterate on code.

• - Begin by ignoring the whole install/egg thing. Get all of the code simply running from source. This will mostly mean adjusting import statements.
• - Once that is confirmed working, then update setup.py so that the install/egg works under this new paradigm.
• - Verify which is preferred, filesystem or egg contents (it should be the filesystem, given the observed sys.path order if the egg is present).
• - Verify that the egg is properly used when using the systemd/start-eddn-service script without --from-source argument.

[Athanasius]

In the meantime this has mostly been addressed by the systemd/start-eddn-service script, with its --from-source argument, which uses:

cd "${SRC_DIR}/src/eddn"
python ${SERVICE_CAMEL}.py --config "${CONFIG_OVERRIDE}"

i.e. runs the file directly, but specifying the config file to use so it can actually be found.

There may still be some wrinkles with respect to other source files being found in the egg, not the raw files, but this at least works for the 'entry point' source files.

Also, 'egg' is deprecated in favour of 'wheel', and there are changes afoot with respect to setup.py as well, so this will likely be entirely redone under python3 anyway.