pkg: Support upstream metadata #5
Conversation
CyberTailor
force-pushed
the
upstream
branch
2 times, most recently
from
97f1ba9 to
938e5d2
Compare
|
Some tests make sense only for Portage, how to handle this? |
When a feature is missing from the PM, raise |
|
Good idea, now |
gentoopm/basepm/pkg.py
Outdated
| def upstream(self) -> typing.Optional[PMUpstream]: | ||
| """ | ||
| Get the package upstream metadata (or ``None`` if unavailable). | ||
| """ |
There was a problem hiding this comment.
I'm wondering if the distinction for None is really useful here. After all, none of the "upstream" keys are mandatory, so there's no technical difference between "missing" upstream metadata and "empty" upstream metadata, so it feels like asking consumers to separately detect two equivalent cases.
There was a problem hiding this comment.
I reduced the number of keys with such distinction
gentoopm/portagepm/pkg.py
Outdated
| return tuple(PortagePackageMaintainer(m) for m in meta.maintainers()) | ||
|
|
||
| @property | ||
| def upstream(self) -> typing.Optional[PMUpstream]: |
There was a problem hiding this comment.
To be honest, this isn't really consistent with gentoopm design. The idea was to provide thin wrappers over PM data types, not copy everything over. So in this case you'd return a PortageUpstream object that would provide accessors for all the shit.
Or well, technically, you wouldn't make a special "upstream" subclass about it and just put them as top-level properties of package class.
There was a problem hiding this comment.
Did I get it right this time?
Fully supported only for Portage, pkgcore can return only remote-ids.
Fully supported only for Portage, pkgcore can return only remote-ids.