[email protected] wrote:
> http://cr.opensolaris.org/~johansen/webrev-xpub-1/
transport/__init__.py:
- Can you simply do
from .transport import Transport, ImageTransportCfg, GenericTransportCfg
(and so on) or does that break badly? Or is there a reason you don't
want to do that?
transport/engine.py:
- line 853: Why would you get EROFS when opening an object for reading?
- line 879: why wouldn't this be set by the READDATA line above?
transport/repo.py:
- line 598, 625, et al: dict literals shouldn't have a space before the
colon.
- line 1167: "tranasaction" -> "transaction"
- line 1376: "it's" -> "its"
transport/transport.py:
- line 146: return self.__policy_map.get(policy_name, False)
- line 151: double space
- line 154: self.__publishers.pop(publisher_name, None)
- Your model for intersecting multiple origins with publication is
interesting. I suppose it wouldn't actually happen very often, but if
it did, and you ended up sending different parts of a transaction to
different depots, things might get a little confused.
- line 2116: "an close" -> "a close"
misc.py:
- line 376: what's this change intended to fix? Things may very well have
changed, but I would expect that if "f" is a file-like object, then it
should have "close()" called on it, too.
pull.py:
- line 137: the "error" here will override the "error" function you use
on line 146.
- line 139: why is this declaration needed? Ditto in other places where
these names are only being read and not assigned to. (Similarly in
importer.py and merge.py.)
- line 148: "% cache_dir" should be outside the _()
- line 396: is the try/except block unnecessary? (Same in importer.py,
line 1441.)
After seeing setup_publisher() and setup_transport() several times in the
various utilities, I wonder if they should be made convenience functions in
the client.transport module.
Danek
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
