| 1 |
On 30 May 2015 11:14, Mike Frysinger wrote: |
| 2 |
> Rather than each module implementing its own shim around the various |
| 3 |
> methods for accessing extended attributes, start a dedicated module |
| 4 |
> that exports a consistent API. |
| 5 |
|
| 6 |
and it looks like i just missed the new pym/portage/util/xattr.py module. |
| 7 |
i'll have to merge that in too. but first about the API. |
| 8 |
|
| 9 |
the current code does: |
| 10 |
import portage.util.xattr as _xattr |
| 11 |
and then the _xattr module provides three functions: |
| 12 |
getxattr |
| 13 |
listxattr |
| 14 |
setxattr |
| 15 |
which is kind of confusing as both pyxattr and python 3.3 (via the os module) |
| 16 |
provide these functions, but with different signatures. for example: |
| 17 |
os.getxattr(path, attribute, follow_symlinks=True) |
| 18 |
xattr.getxattr(item, attribute[, nofollow=False]) |
| 19 |
i think this is why the pyxattr module has actually marked all of these as |
| 20 |
deprecated. |
| 21 |
|
| 22 |
mine is: |
| 23 |
from portage.util._xattr import xattr |
| 24 |
and then the xattr module provides the standard pyxattr functions: |
| 25 |
xattr.get |
| 26 |
xattr.get_all |
| 27 |
xattr.list |
| 28 |
xattr.remove |
| 29 |
xattr.set |
| 30 |
and i omit all of the confusing variants. the reason i don't put the functions |
| 31 |
into the module itself is so that we can more xattr related functions which i've |
| 32 |
already done with the context manager: |
| 33 |
from portage.util._xattr import preserve_xattrs |
| 34 |
with preserve_xattrs('/some/file'): |
| 35 |
... |
| 36 |
|
| 37 |
so if there's no reason to keep portage.util.xattr, i'll kill it and move the |
| 38 |
new quickpkg usage to _xattr. |
| 39 |
-mike |
Archives