diff --git a/PLUGINS.md b/PLUGINS.md
index 6fd20ef9..71aaec7a 100644
--- a/PLUGINS.md
+++ b/PLUGINS.md
@@ -163,6 +163,19 @@ circular imports.
For an example of how this is done, look at the code in `plugins/common_coreutils.py`
and the usage of these functions in other core plugins.
+Plugins may import additional code modules from `load.py` in the usual way. Note
+that using an import statement like `import my_module` or `from my_module import
+foo` will only import one module with that name **across all plugins**. This can
+be used to create a shared library used by several plugins if used carefully,
+but may create a conflict if another plugin also has a module of the same name
+containing different code. For example if two plugins both contain a
+`widgets.py` file and both do `import widgets`, only one of the two modules will
+actually be imported.
+
+To avoid this issue, use a relative import statement such as `import .widgets`
+or `from .widgets import foo` to ensure that the module is loaded from the
+current plugin, even if the name conflicts with another plugin's code.
+
---
## Logging
* Nothing outside of monitor.py uses this, but it's of the same nature as
StationName and MarketID, so do this for consistency.
For now we'll leave monitor.stationservices as-is.
1. EDDB plugin tracked this for keeping the Station link text up to date.
* So moved it to monitor.state['SystemPopulation'].
* PLUGINS.md updated to cite this.
* PLUGINS.md also updated to note state entries that are set to None if
remote multi-crew is detected.
* Minor grammar edit only in PLUGINS.md (I was checking if it explicitly
stated what data is expected in the synthetic 'StartUp' event, it doesn't).
* First changes to move some monitor properties into the monitor.state
dictionary. This is for system or body data.
* Re-factored the generation of 'StartUp' event into
`EDLogs.synthesize_startup_event()`. It's done in two places, so was
anti-DRY.
* In general any bulk setting of system & body data is now done in the
same order for comparison clarity.
* A little of the location tracking has been duplicated from plugins/eddn.py.
This is with a view to switching *it* to using the state version.
* Added `capi.request.<endpoint>` killswitches at appropriate call points.
* Added `eddn.capi_export.<type>` killswitches. This allows for killing
just the EDDN export of such CAPI-derived data, without stopping the actual
queries, as other plugins/functionality might still have harmless use of
the data.
* PLUGINS.md: Actually describe the contents of `data` passed to plugins, and
point out it might not always contain market or shipyard data. This is
not only because of the new killswitches, but could already have happened
if the station/port docked at didn't have the services.
* Some misc typing cleanups.
* Additional Allowed Imports `from companion ...`.
* Plugin authors will still need to chain `cmdr_data_legacy()` to calling
`cmdr_data()`, but with sanctioned access to `data.source_host` they can
then determine the galaxy data source.
* Re-worked the documentation for CAPI data a little to make all of this as
clear as possible.
* This did, however, remind me that the `data` passed into `cmdr_data()`
is an amalgam of `/profile`, `/market` and `/shipyard` queries.
This means that the data.source_endpoint is **not correct for all of
the data and its use**. As such I had to pass 'hard coded' values into
the function from the various CAPI export functions. They know what it
is they're exporting.
* As this reminded me that "CAPI `data` is actually a `CAPIDATA`", I've
documented that in PLUGINS.md, but with a dire warning against relying on
any of the extra properties.
David Sangrey
Inutt
David Muckle
Connor
aussig
Athanasius
Athanasius
Chris