Summary: | =app-portage/gentoolkit-0.3.0.6-r3 with >sys-apps/portage-2.1.10.49 - FileOwner raises unexpected AttributeError exception | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Alex Brandt (RETIRED) <alunduil> |
Component: | Tools | Assignee: | Portage Tools Team <tools-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bpshacklett |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 346443 | ||
Attachments: | return string from gentoolkit's Package.__str__ |
Description
Alex Brandt (RETIRED)
![]() Created attachment 316121 [details, diff]
return string from gentoolkit's Package.__str__
This seems to be a bug in gentoolkit. It looks like the problem is that gentoolkit has a Package class which has a __str__ method which gets called when this example code is run, but that method doesn't actually return a string, and instead returns a Package, so when the portage code tries to split the variable which it expects to be a string, it can't.
This patch casts the variable returned by the __str__ method into a string.
(In reply to comment #1) > This patch casts the variable returned by the __str__ method into a string. Just curious but is it convention to use str in gentoolkit rather than unicode? (In reply to comment #2) > (In reply to comment #1) > > This patch casts the variable returned by the __str__ method into a string. > > Just curious but is it convention to use str in gentoolkit rather than > unicode? I used str() because gentoolkit has to be able to work with python3 as well, which automatically is using unicode, and doesn't have the unicode() method. Regardless, I ran a couple tests and it looks like by the time the variable is passed into the portage code, it is recognized as being of type unicode. FYI, I'm not a gentoo or a gentoolkit dev, so if you want a completely authoritative answer, I would ask one of them. With the proposed patch to gentoolkit everything works as expected for this test case. The patch has been committed to the gentoolkit repository and can be tested/verified with gentoolkit-9999 The 9999 version works perfectly. Loving the performance boost it buys as well. Thanks for the good work guys. Looking forward to a stable release of this codebase. Released in gentoolkit-0.3.0.7 |