patch to propagate initialization errors to the emitters in the updates-daemon

Hi,

I'm working on a project that has a yum plugin that does
some things
that can conceivably fail as part of its init_hook .  I'd
like for the
plugin to be able to propagate error messages from init_hook
failures
up to pup, so that pup can display the error messages to the
user.

One complication is that the user may be using a locale that
is
different than the locale that yum-updatesd is running with.
 This
means that we need to pass the translation domain
"e.g.,
'yum-updatesd' or 'messages' or 'mypluginname'" along
with the error
message so that pup can look up the appropriate translation
for the
language the user is logged in as.

Another complication is that the user may not be logged in
when the
error happens.  I'm not sure of a good solution to this
problem (short
of queuing the messages which could get pretty complicated),
so it's
one I'm sort of punting on.  Note the user will probably
eventually
see the message because yum-updatesd will try the same
operation again
after the update interval times out and fail again.  Also,
if pup
calls the CheckNow() api on startup then the user will get
the message
when they first login, so I don't think its a huge deal.

It might be interesting to pass the translation domain as
part of the
other signals that yum-updatesd emits, but that will break
API.  I
don't know that's okay.

Thoughts?
--Ray

_______________________________________________
Yum-devel mailing list
Yum-devellinux.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel

Hi again,

> I'm working on a project that has a yum plugin that
does some things
> that can conceivably fail as part of its init_hook . 
I'd like for the
> plugin to be able to propagate error messages from
init_hook failures
> up to pup, so that pup can display the error messages
to the user.

By pup above, I mean pupplet.

--Ray
_______________________________________________
Yum-devel mailing list
Yum-devellinux.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel

On Wed, 2007-02-28 at 16:41 -0500, Ray Strode wrote:
> I'm working on a project that has a yum plugin that
does some things
> that can conceivably fail as part of its init_hook . 
I'd like for the
> plugin to be able to propagate error messages from
init_hook failures
> up to pup, so that pup can display the error messages
to the user.
> 
> One complication is that the user may be using a locale
that is
> different than the locale that yum-updatesd is running
with.  This
> means that we need to pass the translation domain
"e.g.,
> 'yum-updatesd' or 'messages' or 'mypluginname'"
along with the error
> message so that pup can look up the appropriate
translation for the
> language the user is logged in as.

Seems mostly reasonable, although a tad kludgy.  But like I
said when we
were talking on IRC, I don't know how to avoid that.

> Another complication is that the user may not be logged
in when the
> error happens.  I'm not sure of a good solution to this
problem (short
> of queuing the messages which could get pretty
complicated), so it's
> one I'm sort of punting on.  Note the user will
probably eventually
> see the message because yum-updatesd will try the same
operation again
> after the update interval times out and fail again. 
Also, if pup
> calls the CheckNow() api on startup then the user will
get the message
> when they first login, so I don't think its a huge
deal.

I think that this is okay.  puplet _does_ call the refresh
and if your
error was "run some application", that application
could also ask for
the refresh.

> It might be interesting to pass the translation domain
as part of the
> other signals that yum-updatesd emits, but that will
break API.  I
> don't know that's okay.

I think without a real need for it, I'd lean against
breaking the API.
Especially as we could add another signal with the
translated bits if we
really want and then apps could watch for whichever they
want.

The only part that I'm a little less sure if anyone has a
better way is
the translation domain bits for the plugin.  That feels kind
of ugly and
more like something that's related to the plugin instead of
the
exception.  Then again, I wasn't aware of PluginYumExit
until recently
anyway, so maybe I'm the wrong person to comment there 

Jeremy

_______________________________________________
Yum-devel mailing list
Yum-devellinux.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel

Following up with our chat on IRC...

On Wed, Feb 28, 2007 at 04:41:32PM -0500, Ray Strode wrote:
> Hi,
>
> I'm working on a project that has a yum plugin that
does some things
> that can conceivably fail as part of its init_hook . 
I'd like for the
> plugin to be able to propagate error messages from
init_hook failures
> up to pup, so that pup can display the error messages
to the user.
> 
> One complication is that the user may be using a locale
that is
> different than the locale that yum-updatesd is running
with.  This
> means that we need to pass the translation domain
"e.g.,
> 'yum-updatesd' or 'messages' or 'mypluginname'"
along with the error
> message so that pup can look up the appropriate
translation for the
> language the user is logged in as.

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.
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 ?

> Another complication is that the user may not be logged
in when the
> error happens.  I'm not sure of a good solution to this
problem (short
> of queuing the messages which could get pretty
complicated), so it's
> one I'm sort of punting on.  Note the user will
probably eventually
> see the message because yum-updatesd will try the same
operation again
> after the update interval times out and fail again. 
Also, if pup
> calls the CheckNow() api on startup then the user will
get the message
> when they first login, so I don't think its a huge
deal.
> 
> It might be interesting to pass the translation domain
as part of the
> other signals that yum-updatesd emits, but that will
break API.  I
> don't know that's okay.
> 
> Thoughts?

This patch should speed up the startup time of the update
daemon, as
YumBase.doConfigSetup is only called when updatesCheck is
executed
(either when called by puplet directly, or after the timeout
interval),
instead of when the daemon is initialized.

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 ?

This also forces people to initialize PluginYumExit with a
value instead
of just being able to 'raise PluginYumExit'.

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.

What does everyone else think ?

luke
_______________________________________________
Yum-devel mailing list
Yum-devellinux.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel

Hi,

On 3/23/07, Luke Macken <lmackenredhat.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
_______________________________________________
Yum-devel mailing list
Yum-devellinux.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel

On Tue, 2007-03-27 at 15:30 -0400, Ray Strode wrote:
> Updated patch, attached.

Looks good; committed

Jeremy

_______________________________________________
Yum-devel mailing list
Yum-devellinux.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel