Revert "Updates to PVPostionerSoftDone"

[gfabbris]

Reverts #1005

[gfabbris]

@prjemian: I think this will work. You can actually see the changes here, and we can just close this if we want to keep it.

[prjemian]

we can just close this if we want to keep it.

not sure I understand. Can you rephrase?

[prjemian]

This branch did not trigger CI yet. It passed pytest -vvv ./apstools/devices locally with no failures.

[gfabbris]

I mean that, since it was already merged into the 916-PVPositionerSoftDone-update branch, if you want to keep these changes, then we don't merge this PR.

[gfabbris]

By the way, forgot the add the comments I had for this:

Main proposed changes:

• Keeps setpoint and readback as normal EpicsSignal. But now, changes to the setpoint are sent to the target through a subscription.
• Forces the done signal to be False when the device is moved.
• Changes the default value of use_target to False. There is one disadvantage of using the target signal: if you change the setpoint "manually" in EPICS (and the device moves to the new setpoint), the Bluesky device will not know that it is inposition because target was not updated. Therefore, I recommend to set use_target=True only when EPICS changes the setpoint value while ramping (like in the Lakeshore 340).
• Removes python 3.8 from unit tests. It is leading to an import error, see error.

[gfabbris]

This branch did not trigger CI yet. It passed pytest -vvv ./apstools/devices locally with no failures.

I think these are the CI, got triggered when I accidentally merged: https://github.com/BCDA-APS/apstools/actions/runs/10568053789

[gfabbris]

It looks like this error was due to a bug in setuptools that got fixed, it works now (https://github.com/gfabbris/apstools/actions/runs/10584246206/job/29328167045?pr=4). Should we add it back?

[prjemian]

It looks like this error was due to a bug in setuptools that got fixed, it works now (https://github.com/gfabbris/apstools/actions/runs/10584246206/job/29328167045?pr=4). Should we add it back?

It was not a problem when the SpecWriterCallback2 was developed:

• Write data to SPEC files point-by-point #1008

[prjemian]

@gfabbris : With #954 merged, can you close this PR?