Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Defer setup to avoid module import-time side-effects #13

Merged
merged 8 commits into from Feb 13, 2018
Merged

Conversation

Gadgetoid
Copy link
Member

This PR makes several "friendly neighbour" changes to the Automation HAT library:

  • Do not perform any module setup on import
  • Do not output any messages/text on import
  • Use ImportError instead of hard exit() for "friendly" import error messages

An experimental Default class, which shadows all the methods used in Automation HATs ObjectCollection class is used to trap calls to the library and call ensure_setup before handing them off to the correct class.

The default class is triggered only once. After this default class has been triggered, it will be replaced by instances of the actual Relay, Input, Output, etc classes for subsequent calls.

The setup method will be called automatically by the first call to an Automation HAT method. It will raise a RuntimeError if run again. If you want to setup with custom settings - ie: quiet mode - then automationhat.setup() should be the first thing you call after import.

See here for details of the problems import-time side-effects can have: https://www.raspberrypi.org/forums/viewtopic.php?f=32&t=193502&p=1212488#p1212488

@Gadgetoid Gadgetoid added this to the Version 0.0.5 milestone Sep 19, 2017
@Gadgetoid
Copy link
Member Author

I've refactored this to 094d6c4 from attempt 1 which relied on far too much runtime morphing of the code and was too complicated for its own good.

This attempt is markedly better, but still suffers from issues with disambiguation of Automation HAT from Automation pHAT which must be done at runtime but cannot be done upon import.

Presently Relay one, two and three are all mapped onto Automation pHATs one relay, which is suboptimal. Perhaps a RuntimeError should be raised when accessing a relay which doesn't exist, and relay one should map correctly for Automation pHAT.

Similarly Analog four exists for both Automation HAT and pHAT presently, but should only be usable on HAT.

@Gadgetoid Gadgetoid self-assigned this Nov 21, 2017
@Gadgetoid Gadgetoid added the bug label Jan 24, 2018
@Gadgetoid Gadgetoid merged commit 4be639a into master Feb 13, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant