Move settings files to include the class name.#349
Conversation
Barecheck - Code coverage reportTotal: 97%Your code coverage diff: 0.00% ▴ Uncovered files and lines
|
This means that, if the class of a Thing is changed in config, its settings are saved separately. I've had to add an argument to `ThingServerInterface` to pass in the class name. This then touched a bunch of test code, which is updated. I tried a previous, more complicated way of getting the Thing class, but it relied on `ThingServer.things` which may not be populated when it's needed. I've also added a mocked `_get_server` method which raises an error - this should make `MockThingServerInterface` easier to debug.
rwb27
force-pushed
the
add-class-to-settings-file
branch
from
4e40954 to
70ed1aa
Compare
|
The readthedocs build failure seems to be a GitHub issue, it couldn't pull. There's no way to re-run that job (and the local Sphinx job worked). I'm guessing review comments will involve at least one CI re-run, and I'm going to assume that will fix it. If not, we can deal with it then. |
|
I think we might want to swap the filename around so it starts with settings, e.g. Settings-ClassName.json. If/when there are other files in the folder, it seems sensible to me that the LabThings settings files all sit together in a directory listing. Opinions welcome on camel vs snake case - I don't usually name files in camel, but it saves converting the class name... |
This ensures that, if there are other files in the folder, all the settings.json files appear together in a `dir` listing.
This adds to the tests for thing_server_interface, checking that the settings filenames are as expected when generated in the context of a server.
bprobert97
left a comment
bprobert97
left a comment
There was a problem hiding this comment.
Happy with changes, just need to fix some tests now that Settings- comes at the start of the file name
2 participants
This means that, if the class of a Thing is changed in config, its settings are saved separately.
I've had to add an argument to
ThingServerInterfaceto pass in the class name. This then touched a bunch of test code, which is updated. I tried a previous, more complicated way of getting the Thing class, but it relied onThingServer.thingswhich may not be populated when it's needed.I've also added a mocked
_get_servermethod which raises an error - this should makeMockThingServerInterfaceeasier to debug.Closes #290