[Yum-devel] patch to propagate initialization errors to the emitters in the updates-daemon

Ray Strode halfline at gmail.com
Fri Mar 23 15:19:00 UTC 2007


Hi,

On 3/23/07, Luke Macken <lmacken at redhat.com> wrote:
> I'm ignorant in the ways of translation domains, so I'm not sure if
> stuffing this in the PluginYumExit exception is the best place or not.
It might be better for a plugin to be able to advertise it's domain
somehow instead of doing it per exception.  One advantage of doing it
per exception, though, is that str(e) will return a translated string.
 Maybe that's not important, though.  If plugins wanted to, they could
subclass PluginYumExit (PluginFooYumExit ?) and sneak the translation
in that way, too.

> I also have no knowledge as to what your yum plugin actually does, but I
> assume throwing the puplet an error code instead of a message +
> translation domain won't suffice ?
Right, the error is specific to the plugin, so pupplet doesn't know about it.

> os.environ['PWD'] doesn't seem to exist when I run the update daemon via
> `sudo ./yum-updatesd.py -f`, which causes restart() to explode.  Maybe
> os.getcwd() instead ?
Oh right, sudo strips the environment I think.  The point of the chdir
call is to make sure that we're in the same directory we were started
in, in case argv[0] is relative.

doing
  os.chdir(os.getcwd())
doesn't make sense.  That would be a noop.  There is two ways we could
approach this:

1) add initial_directory = os.getcwd() at the top of the file and then
do os.chdir(initial_directory) instead of os.chdir(environ["PWD"])
2)  just say the odds of
   - the current directory getting changed by yum-updatesd after startup
   - PWD not being set in the environment
   - yum-updatesd getting invoked directly via a relative path
all happening are pretty small, and just skip the chdir call if
environ.has_key("PWD") fails

I don't care which approach we go with.  1) seems easy enough, so I'll
go for that unless people think 2 is better.

> This also forces people to initialize PluginYumExit with a value instead
> of just being able to 'raise PluginYumExit'.
That's true and it's semantic change I didn't mean to introduce.  We
can add a default empty string to the value argument in the
constructor.

> As I mentioned, my translation domain knowledge is non-existent, so
> whether or not this is a good place to stuff this is beyond me.
A translation domain is just a string that says where to look up
translations from.

For apps, the domain is normally is the name of the app.  For
libraries the domain is normally the name of the library.  It
basically is to figure out which .mo file to get the translation out
of.

--Ray



More information about the Yum-devel mailing list