Allow users to disable implicit cleanup

[bennuttall]

Sometimes, you want to write a script which turns on a device, and leaves it on. Let's say you have a cron job to check something periodically, and control a device accordingly. Rather than have the script continuously running, you want to run it regularly. With gpiozero, your script will turn the device on, exit and turn it back off when running implicit cleanup.

I saw on this SO question recently that someone wanted to do this, and they ended up using RPi.GPIO instead.

It should be possible in gpiozero. If we could either have it per-device:

led = LED(2, cleanup=False)

or just in the Device base class:

Device.cleanup = False

led = LED(2)

or provide both?

I'm not certain that's the right API, but you get the idea.

This was originally raised in #323. In fact I almost suggested this at the end (though my suggestion doesn't quite make sense...)

[lurch]

My gut feeling is that cleanup=False is potentially dangerous, so it should definitely be a per-device setting rather than a global Device setting?

[bennuttall]

Per-device makes sense.

[lurch]

Having just read through #323 again, I wonder if we need both cleanup and final_value properties?
(with final_value being needed for those boards like Energenie where we can't read the device's value)

For an LED, if it's on before we run our gpiozero script and we specify initial_value=None, cleanup=False, should the final state of the LED be on or off after the script exits? And similarly if it's off before we run our gpiozero script and we specify initial_value=None, cleanup=False, should the final state of the LED be on or off after the script exits? And if we specify an explicit initial_value, how should that affect the final state of the LED with cleanup=False?
Or am I overcomplicating things, and cleanup will simply leave the pin at it's current state? Might users want a return_to_initial_state setting? 🤷‍♂️ ( @lurch runs away from the can of worms he just opened 🏃‍♂️ 😉 )

[CAM-Gerlach]

@lurch @bennuttall Its been exactly a year since the last comment on this. Is there any realistic plans for its implementation?

To me, this seems like a very basic feature, given how seemingly common scripts that toggle or turn on/off existing devices (e.g. LEDs) are especially among beginners, RPI.GPIO's primary target audience; the alternative is overriding DefaultPin as in #394 which is not particularly beginner-friendly particularly for beginners to Python itself, who may be intimidated by code they don't understand and resort to a different GPIO library instead.

If resolving this issue has stalled and is not a priority for some reason, how much work would it be for a contributor with a few years of Python experience but having not touched the gpiozero codebase to implement a fix for this? How would you advise it be implemented? Thanks.

[CAM-Gerlach]

Also, to be clear, the hack in #394 no longer works due to changes in the gpiozero API in the four years (!) since that issue was raised. Instead, the following approach appears to produce the desired result, albeit with some boilerplate and fragility, two things that gpiozero has design goals of avoiding:

import gpiozero.pins.rpigpio

def close(self): pass
gpiozero.pins.rpigpio.RPiGPIOPin.close = close

gpiozero.LED(..., pin_factory=gpiozero.pins.rpigpio.RPiGPIOFactory())

It could probably be a little cleaner/more correct if I had better knowledge of rpigpio's API and internals, but even figuring out this level of monkey patching is likely beyond the knowledge of most beginners; even for me it took a good amount of digging into the docs, hacking a solution and then trial and error to get it to actually work. I don't see how any newer user could be reliably expected to accomplish this simple task on their own without a strong Python background and a lot of patience.

[lurch]

@CAM-Gerlach See also the linked #803 - if we do add the option to "disable implicit cleanup", what and/or how much of the pin's previous state should we save / restore? How much of the pin's previous state are the various pin libraries able to read? etc. etc.
I think this is probably more of a "design problem" than an "implementation problem" (?) and personally I don't have much time at the moment to have an in-depth think about the API 🙁

[CAM-Gerlach]

@lurch Thanks, yeah I did review that issue as well. I myself have spent far too large a proportion of my time thinking (and re-thinking) through non-obvious API design decisions, so I understand that can consume a lot of time and mental energy.

What is a little confusing to me reading a lot of those issues linked as related, being someone lacking your level of knowledge about gpiozero's inner workings, is where the tight coupling arises between implementing A. the ability to simply disable the existing automatic cleanup routine for a Device (e.g. cleanup={True,False} param to the Device constructor that's been suggested, that simply enables and disables cleanup) and B. making the existing cleanup routine more comprehensive or controllable, to reset the original or a specific value on exit (e.g. a final_value={None, _val_} param). Perhaps you could overload the cleanup parameter to also mean something beyond just enabling or disabling the cleanup routine but I'd think that would be rather confusing for users.

I understand they are conceptually related, but I'm not really sure how the implementation of A. inherently depends on B such that B blocks the implementation of A (which would at least naively seem like it would be the simpler of the two both in concept and in implementation, at least presuming one is familiar with the internals of gpiozero, since its simply offering the option to disable an existing behavior rather than adding a new one). The more one gets into considering the lengths gpiozero can go when restoring the state of a pin, the more orthgonal the problem would seem to become to the one of telling gpiozero to simply not run the cleanup routine at all. However, given your far greater experience with it, I figure there's something I'm missing here.

As to the API of the final_value parameter, the most basic would be passing a value other than None sets that value on close() (independent of whether cleanup is True) and None is the current behavior. The difficulty arises if re-setting the initial value is desired; should None mean "retain the last value after or before gpiozero created the pin object (with the other being represented by e.g. a sentinel constant)? Furthermore, if getting the initial value is not possible with the pin/device type, should gpiozero raise a warning or error, fall back to some default "off/low" state, or simply retain the current value of the pin? These aren't easy questions, but I'm not sure how I see how they aren't orthogonal to the actual issue at hand here, "allow users to disable implicit cleanup", and to an independent cleanup={True,False} parameter separate from any final_value parameter or handling, and thus seem to me to be out to scope here.

[lurch]

Yeah, I guess your 'A' (disable implicit cleanup) is independent of 'B' (set final state / restore previous state), I think my worry was just that if we implemented behaviour 'A' then that might also lead more people to expect gpiozero to do behaviour 'B' ? (IYSWIM)

In any case, as you note this would need to be done at the Device level, and even with "my level of knowledge about gpiozero's inner workings" I wouldn't be comfortable modifying the API of such a fundamental gpiozero class, which should be a job for @bennuttall or @waveform80 . My cleanup and final_value parameters were just suggestions for discussion, not necessarily actual API recommendations.
#SittingOnTheFence 😉