Organizing vendor packages in v1

[rickwierenga]

Now that we have manufacturer specific entry points (GitHub - PyLabRobot/pylabrobot at v1b1 · GitHub, Updating PLR API for machine interfaces discussion) that compose capabilities, the location where these are stored is

pylabrobot.vendor

on the current v1b1 branch. call that option 1.

The alternative (option 2) is to put devices in

pylabrobot.devices.vendor

and keep

pylabrobot.resources.vendor

(see Updating PLR API for machine interfaces discussion - #50 by vcjdeboer, Updating PLR API for machine interfaces discussion - #60 by rickwierenga)

We currently store labware definitions by vendor in pylabrobot.resources.vendor (next to pylabrobot.resources.plate etc. standard files)

---

I like putting vendor modules at the top level (meaning pylabrobot.hamilton, pylabrobot.corning, etc.) that houses all code for that particular vendor, with the rest of pylabrobot.X just being the universal shared code. It’s clean architecturally.

• This makes it easier to see all stuff we have for one vendor, and also makes it possible for vendors to easily just maintain a given directory if/when they start contributing more
• It keeps the pylabrobot.resources library nice and clean and universal.
• Also devices are to a certain extent labware definitions.
• Are we gonna move io and capabilities and the rest of PLR into devices as well?

[rickwierenga]

[CamilloMoschner]

There is a lot to talk about, so I’ll do it step by step

Terminology

I am convinced “Vendor” is the incorrect term here:

The best explanation of the term I found is Investopedia - What is a Vendor:

“A vendor is a party in the supply chain that sells goods and services to companies or consumers. Vendors can be found at various points during the supply chain, including manufacturers, wholesalers, and retailers.”

This means vendor is the superset.

I believe the term we should use here is “Original Equipment Manufacturer” / OEM.

Using the term “vendor” leads to ambiguity:

E.g. in the UK I can buy a CLARIOstar from vendor_1 Wolfsonlabs, vendor_2 eg scientific, or I buy directly from the OEM BMG Labtech (which is vendor_3 by directly selling their product).

Vendors depend on country and moment in time and therefore change a lot.

In contrast, OEMs are much more stable over time and are the source of device design and usage information - i.e. the company we want to actively contribute to and ideally maintain their drivers and resource definitions in PLR.

To be clear, they can still change too: e.g. due to mergers and acquisition - Applied Biosystems was a company until 1997, and was then bought and the name converted into a brand, now owned by Thermo Fisher Scientific → but this change in OEM is happening much less frequently than a change in vendor.

(I’ve made company “brand trees” in the PLR docs resource management section to give more examples and help us navigate this maze: e.g. Corning)

To maximise clarity/minimise ambiguity, I would therefore recommend we avoid the term “vendor” in PLR.

[rickwierenga]

yes OEM is objectively a better name for this

I like the brand tree that we have in resources. If that was ever applicable I would also use it for devices

[CamilloMoschner]

@rickwierenga

If that was ever applicable I would also use it for devices

It is applicable to the same extend as it is for resources: e.g. a Biotek device should nowadays in the Agilent folder

[rickwierenga]

yes

[CamilloMoschner]

@rickwierenga

• This makes it easier to see all stuff we have for one vendor, and also makes it possible for vendors to easily just maintain a given directory if/when they start contributing more
• It keeps the pylabrobot.resources library nice and clean and universal.
• Also devices are to a certain extent labware definitions.
• Are we gonna move io and capabilities and the rest of PLR into devices as well?

I really like the idea of making things easier for OEMs to directly contribute.

To the second bullet point: do you mean that pylabrobot.resources would still exist but instead of resource function definition only contains the resource subclass defintions → i.e. the ontology system in one clean dedicated folder?

To the last bullet point:
Maybe going the other way is easier, what would not go into devices?

[rickwierenga]

@CamilloMoschner

To the second bullet point: do you mean that pylabrobot.resources would still exist but instead of resource function definition only contains the resource subclass defintions → i.e. the ontology system in one clean dedicated folder?

yes exactly

pylabrobot.resources = ontology

pylabrobot.oem = their labware and devices in one place

I really like this split at the top level.

the alternative, just repeating for clean comparison, is:

pylabrobot.resources
                    .oem1
                    .oem2
                    ontology things like resource.py, plate.py, etc.

pylabrobot.devices
                  .oem1
                  .oem2
                  ontology things like io, capability.py, device.py

@CamilloMoschner

Maybe going the other way is easier, what would not go into devices?

if we went that route, probably keep in base level:

• serializer
• visualizer
• config

since these span both devices and resources

[CamilloMoschner]

Is this the current design?

[rickwierenga]

no it is not under oem

you can see the current design on the branch:

GitHub - PyLabRobot/pylabrobot at v1b1