You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was recently thinking of how to best give developers the ability to work on their own instrument drivers, internally maintain them, and deploy them, but without having to keep a fork of instrumentkit. That would help keep people from having code diverge just so that they can have their own drivers.
I think the best way to approach this is to lean on the setuptool entrypoints feature, which would allow multiple packages to register themselves under a common handle that the IK core can then automatically look through.
The text was updated successfully, but these errors were encountered:
I was recently thinking of how to best give developers the ability to work on their own instrument drivers, internally maintain them, and deploy them, but without having to keep a fork of
instrumentkit
. That would help keep people from having code diverge just so that they can have their own drivers.I think the best way to approach this is to lean on the setuptool
entrypoints
feature, which would allow multiple packages to register themselves under a common handle that the IK core can then automatically look through.The text was updated successfully, but these errors were encountered: