Hey everyone! I guess this is the place for PLR development now.
I would like to propose “flattening” the resource hierarchy for “common” resources in PLR. These common resources are tip racks, tube racks, well-plates, tubes, tips, and maybe holders.
This is what we have now:
- Well Plate → Well
- Tube Rack → Tube
- Tip Rack → Tip Spot → Tip (not a resource)
- Some of these may be in a “holder” or not.
From my point of view, this pattern is inconsistent, and as such it makes code harder to understand and develop for and around. For example, it is very hard to write a parser for PLR’s serialized JSON data; the only easy solution being to use PLR itself, which unfortunately is only available in python.
I also have concerns around the current implementations of decks and backends that I would like to get into, which further complicate the task, but lets keep it simple for now.
What I would like to propose is enforcing a simple, flat pattern:
- Deck → [n-RackSpots] → Rack → ContainerSpot → Container
The “flexibility” of assigning anything as a child of anything is not evil, but it does not make sense in 99% of imaginable cases. You can place a well plate in a tube spot, for example.
My proposal only requires:
- Making Tips a Container resource.
- Adding TubeSpots to TubeRacks, to hold Tubes.
- Adding WellSpots* to Plates, to hold Wells.
- Adding ColonySpots to petri dishes, to hold colonies.
- …
- Adding checks to enforce relationships between parents and children of these types, ensuring consistency.
- Refactoring everything that might need refactoring to accommodate this.
WellSpots don’t exist physically, but I don’t think that it should matter. The pattern here is that “spots” are virtual places where stuff can be, in that case a Well, even if it is welded to the plate.
What’s important for this case is the consistency in the usage and extension of PLR.
I have already “forked” PLR to accomplish this with TubeRacks, and make it compatible with my setup. It has been exhausting, unfortunately, and I don’t have the energy to code PRs for everything that needs to happen for a merge.
So lets start here. I would certainly appreciate it.
Best!
Nico