I recently released PLR v0.2 on PyPI. This is the first versioned release in a long time. I was lazy and procrastinating on releasing versions, but plan to be more thorough with this moving forward. In the past, people have been installing PLR from source on the main branch which isn’t great for stability (it doesn’t have versions) or development speed (every commit was treated as a release so every time you change sth it would need deprecation warnings). Versions are much overdue.
From now on, the plr:main branch will be for development. It will be unstable, especially the next few weeks while we nail the new designs. I encourage testing and welcome feedback, but please don’t use it for production stuff without knowing there’s risk!
We have a couple of big changes planned for PLR (see below), and I think when this refactor is done it will warrant our v1 release. This week I am starting to merge some of these changes onto the main branch. The forum discussions have proven super valuable, and I have started playing with implementations to the extent that I am now comfortable testing them slightly more broadly and gathering feedback on implementation/welcoming contributions.
I have roughly lined out what the next two versions/betas will look like.
Upcoming/WIP changes for version 1 beta 1 (see links for motivation/ details)
- refactoring into composition architecture:
- backend params in objects rather than kwargs
- updating tip rack modeling
- json patch serialization format
version 1 beta 2:
- grpc/networked interface:
The machine interface (front end / backend) is almost completely rewritten, so I have moved a ton of stuff to a new module called pylabrobot.legacy so it’s easy to update
from pylabrobot.X import
to
from pylabrobot.legacy.X import
where legacy provides the 0.2 compatible API to ease the transition / enable partial adoption.
I will try to back port changes to 0.2.1 as much as possible, for a while, but unfortunately cannot afford to make this fully maintained for long.
I also am reviving the changelog
might call this 0.3 instead of v1b1 and 0.4 instead of v1b2, but targeting v1 feels right