On 02/15/2011 10:10 PM, James Antill wrote:
On Tue, 2011-02-15 at 20:29 +0200, Panu Matilainen wrote:
On 02/15/2011 05:07 PM, James Antill wrote:
Technically this is an API change, but I really hope nobody is relying
on it.
API users shouldn't really see a difference as it's depsolve.py imports
the moved flags with the original name.
The "problem" is that before you could do:
yum.rpmsack.yum.blah
yum.rpmsack.yum.depsolve.blah
...but now that import is gone, so neither of the above are valid (and,
again, I really hope nobody was doing that).
Eww. Yes somebody could have done that, but do you consider it a
legitimate use? There are of obviously loads and loads of python modules
where a module imports something from another module with the sole
purpose of making it part of that module's API, but I don't think every
single import modules do for their own needs can be reasonably expected
to be part of its API and remain untouched forever after.
Consider module "foo" importing "os", because it needs stuff from there
to do its business. Somebody is developing a piece of code utilizing the
"foo" module, and notices "hey its importing os, how convenient - now I
dont have to add my own os import as I can just use foo.os." Legitimate?
I dont think so... and me thinks the case we're discussing here is
similar. Unfortunately python doesn't have a good way of expressing the
intent of an import (short of doing "import foo as _foo" for everything,
but AFAIK nobody does that, small wonder... :)
That said, there are other ways to make rpmsack work in config too,
including doing the rpmsack import inside _getsysver() function to avoid
the loop on initial import.
- Panu -
_______________________________________________
Yum-devel mailing list
[email protected]
http://lists.baseurl.org/mailman/listinfo/yum-devel
