As Crappy keeps growing, more and more hardware of the LaMcube laboratory is implemented.
Having an always larger collection of hardware in Crappy is not desirable for several reasons :
Maintaining the associated code should be up to the users and not to the developers
It makes the module look more complex than it really is
It increases the risk of crash at import
Some of the implemented hardware is not available anymore at the LaMcube, making it impossible for developers to provide support if requested
Therefore, it would be desirable to move most of the implemented hardware to a second independent module (say crappy.collection), that would only contain code for driving hardware.
Users of any horizons would be encouraged to share the code for their hardware in crappy.collection, to make it available to everyone.
There would however be no guarantee that this code works, and the maintenance would be up the the person uploading the code.
Broken code could be removed by crappy's developers in case it makes the entire module crash.
Implementation
This second module would be managed in the same repository, and built at the same time than Crappy (using this architecture for example).
crappy.collection would likely import crappy, but the opposite would not be true.
The structure of crappy.collection would be very simple, with one folder per type of object.
Each folder would contain an __init__.py file, potentially where the missing modules would be managed.
Even with a second module containing the code for driving hardware, there would still be Actuators, Cameras and InOuts in Crappy. The remaining code would be for :
Objects used for demonstration in the example and documentation scripts
Objects put forward and actively maintained by the developers
Objects used by a large base of users
In summary, crappy.collection would be a code base with a permissive contribution policy, and loosely maintained by crappy's developers.
It would allow users to distribute their code with Crappy, without having to match the code quality standards of the main module.
Open questions
At that point, there are still open questions about the implementation :
How to manage the potential version conflicts between crappy.collection and the main module ?
How to manage the missing external dependencies in crappy.collection ?
How to make it clear which objects are available and which are not, given the currently installed dependencies ?
Where should users be encouraged to push their contributions ? On the develop branch ? Or another one ?
Would it make sense to protect one's contribution using the CODEOWNER feature ?
Rationale
As Crappy keeps growing, more and more hardware of the LaMcube laboratory is implemented. Having an always larger collection of hardware in Crappy is not desirable for several reasons :
Therefore, it would be desirable to move most of the implemented hardware to a second independent module (say
crappy.collection), that would only contain code for driving hardware. Users of any horizons would be encouraged to share the code for their hardware incrappy.collection, to make it available to everyone. There would however be no guarantee that this code works, and the maintenance would be up the the person uploading the code. Broken code could be removed by crappy's developers in case it makes the entire module crash.Implementation
This second module would be managed in the same repository, and built at the same time than Crappy (using this architecture for example).
crappy.collectionwould likely import crappy, but the opposite would not be true. The structure ofcrappy.collectionwould be very simple, with one folder per type of object. Each folder would contain an__init__.pyfile, potentially where the missing modules would be managed.Even with a second module containing the code for driving hardware, there would still be Actuators, Cameras and InOuts in Crappy. The remaining code would be for :
In summary,
crappy.collectionwould be a code base with a permissive contribution policy, and loosely maintained by crappy's developers. It would allow users to distribute their code with Crappy, without having to match the code quality standards of the main module.Open questions
At that point, there are still open questions about the implementation :
crappy.collectionand the main module ?crappy.collection?developbranch ? Or another one ?