🚸 Easier way to add a ULabel to a transform

[falexwolf]

We have this pattern quite frequently meanwhile:

import lamindb as ln

ln.context.uid = "taasWKawCiNA0000"  # <-- autogenerated by ln.context.track()
ln.context.version = "2.3"
ln.context.track()
is_project1 = ln.ULabel(name="project1").save()
is_prototype = ln.ULabel(name="prototype").save()
ln.context.transform.ulabels.add([is_project1, is_prototype])

It'd be nice if the last line was simpler. For instance,

ln.context.ulabels.add(["project1", "prototype"])

This would error if the two strings (["project1", "prototype"]) weren't registered as ulabels, yet.

Not sure whether it makes a big difference. 🤔

WDYT? @sunnyosun @Zethson

[falexwolf]

I see two main questions:

1. Do we want to allow string values rather than records broadly across the API by overloading .add() etc.?
2. Do we want to add a .ulabels to property to .context?

I'm pretty sure we want (1) but not (2).

Why not 2?

People should develop clear intuition for working with records as opposed to every other Python class. Hence, transform.ulabels matches the target intuition, whereas Context is a non-Record.

[Zethson]

I strongly agree with not supporting 2.

Concerning 1:
Pro:

1. It's convenient and something that I intuitively tried when I got started with lamindb very early on. A good API is intuitive.
2. lamindb & bionty can be super verbose. We make things very explicit which I think also has a lot of value but oh boii it can be a lot of lines.

Con:
However, I also think that there's value in teaching people that there's only one way of working with lamindb and that's working with records. I think that otherwise, people will constantly try to do anything with pure strings and expect magic under the hood that we don't have.

I'm probably 60/40 in favor of doing it, yes.

[falexwolf]

Ok, we're aligned!

[falexwolf]

Related internal discussion.