Job tags

[kofalt]

• Provide more structure around gears, types of gears, and how they're referenced
• Launch gears as specified in the (as yet unpublished) spec, with some temporarily workarounds
• Tag jobs with their name and type for future use
• Use new upload endpoint
• Add some new gears
• Change job rules to use new gears!

Of interest to @gsfr, @rentzso, and @ryansanford.

[rentzso]

Can we remove this method and use Category.classifier.value, Category.converter.value, etc in lines 57-59?
It seems cleaner to me.
You avoid the string conversion in line 142 also.

[kofalt]

Hmm, not a bad idea. I guess it depends more generally on how we'd like to use enums in the code base.

The downside of that approach is that it wouldn't work if the enums aren't string-based, where the current approach would (if I used self.name in that function rather than self.value).

My eventual intention was that if we use enums more, we'd make a small helper class that does it for you, and let it handle the setup. Let me try that once and see how it feels.

[rentzso]

LGTM just a suggestion

[kofalt]

So it turned out, there was a lot better way to make enums 😄

As proposed, I changed self.value to self.name so it'll work with non-string enums, moved it to util, and made the Category enum in a much simpler way. I left the str operator since it makes sense that you're converting from an enum to a string. Let me know if that looks better.

[rentzso]

It feels a little weird that we overrides str when we can use .name and .value more flexibly, but I don't want to block on this. So feel free to merge.

[kofalt]

Cool. We can change that in the future for sure; to me it felt more explicit that you're converting an enum to a string. Open to further discussion.

[rentzso]

My point is that converting an enum to a string doesn't seem like a standard operation, except for logging.
More proper seems to get the value of an enum or its name.
Then it's perfectly fine for me to do string conversion if needed.

[kofalt]

Hmm, yeah I see what you're saying. I'm a little more used to type conversion, and more specifically I'm used to enums being types rather than complex objects.

And since they are complex objects, we may as well use their properties. I'll probably switch things around next time I touch this code or make a new enum.