Cristian Le

For the case where I needed it, it was because I was: - working on a package review chain, so I need the NVR to be as in the spec...

One option would be to allow `package` to be a `str` or a `dict`, the latter accepting `name`, `install`/`remove` and `missing` for the `prepare.install`. I don't think we should support...

What do you think about putting these into a package `tmt.containers` and moving the remaining implementations there as well.

Cool, I've moved the stuff around, I think after this the only things left to move would be `Common` and the Exceptions? Otherwise everything else would still be under `utils`...

> `__future__.annotations` sounds good, I'm much less fond of stub files, it always felt detached from the code & two places that need to be updated when changing signatures. I...

> > I was thinking stub files as additive to keep things cleaner from parts like `@overload`, but indeed I can see it can easily get out-of-sync. There is one...

Attempt2. This time I've separated the usage into `tmt.container` and vanilla `dataclaess.dataclass`. One that is rather ambiguous is `tmt.queue.Task`, wondering if that should also be covered, maybe by a different...

I think for now to get the first part of splitting the `container` logic to its own package, should be ok. We can workshop the requirements more in the attrs...

> Are we sure about the name `container`? I don't have a better one myself, just raising it as I imagine it could clash with lxc nomenclature. Better naming for...

:thinking: What about decoupling the plugins into their own sub-projects? That way they don't need to `try import` at all. They could live in the same repo under subdirectories and...