Python applets need to make their dependencies explicit to the user

[Mark Lee]

On the forums and on IRC, there are too many questions with regards to Python applets and their dependencies. Due to the way that the autotools work, it's not feasible to use ./configure to detect all of the Python modules (some need X running, etc). Python applet developers need to be able to notify the user (not through the console) that some (or all) of its dependencies are not installed, and directions for how to install it.

[Julien Lavergne (gilir)]

I isolate the python def to test it.

[Mark Lee (malept)]

The only thing wrong with it is that the leading whitespace is a bit off. Otherwise, I've tested it in desktop-agnostic and it works fine. I'll see if I can add it to some of the python applets in moonbeam's awn-extras branch.

[pavpanchekha (pavpanchekha)]

Similar fix available in AWNLib. Methods should probably be looked at and have one chosen (AWNLib would change to whichever one was decided on.)

PyAWN Pros:
Multiple modules at once
Link to Wiki

AWNLib Pros:
Provides list of distributions and packages
Text is, in my opinion, better.

[Mark Lee (malept)]

The reason why I didn't go the route of providing a list of distributions and packages is because that information should not be stored in the source code. We're already documenting it on the wiki, so why bother duplicating the information?

Also, I respect your opinion on the text, but I disagree with that statement. My text gives users reasons why the applet may not be working. Although now that I think about it, it would probably be good if the name of the applet were passed to the function, which yours does do (in a roundabout way).

[pavpanchekha (pavpanchekha)]

My point against the text is that you're putting another step between the user and the applet. If the package name is there, you double the workload for the developer (in the WORST case) but the user benefits greatly if, for example:

Their internet is slow
The wiki is slow
They don't have an internet connection (though this is unlikely)

Which means that the user can fairly quickly open synaptic, click install and click OK, as opposed to going somewhere unknown (which may not have been updated in a while, our wiki isn't quite that good yet), finding something unknownish, and then installing it. Plus, the pyawn method requires a restart of the applet, as opposed to just clicking OK. I personally dislike restarts of AWN (which is what the average user would do, as opposed to removing/adding the applet) since I have to reenter passwords, set audio devices, and such.

All of which is quite annoying.

Plus, if you add the disto packages, you can then add some sort of autodetection of distro to make life more simple for the user (I use Mepis but only Ubuntu and Fedora are listed here, or there are hundreds here, I'll never find Debian!).

In other words, putting the text in the dialog has an open road onwards, linking to the wiki:
1. Breaks the flow of the user
2. No clear path to improvement

Plus, it assaults the user with popups which is NEVER good.

[Mark Lee (malept)]

> If the package name is there, you double the workload for the developer (in the WORST case)

I don't think it's the job of the applet developer to find out the exact dependencies for each and every distribution that their applet's users may run. It should be a collaborative effort, hence why it's in the wiki.

> as opposed to going somewhere unknown (which may not have been updated in a while, our
> wiki isn't quite that good yet), finding something unknownish, and then installing it.

Conversely, the dependencies for distribution X in an applet's source could not have been updated in a while. I find this particular argument not very relevant.

I don't like the fact that you call the wiki "somewhere unknown". It's the official wiki, not some Joe Blogger's "HOWTO install Awn in three easy steps". Additionally, I don't exactly understand what you mean by "finding something unknownish". The exact package names for the distributions listed are named, and if someone reports that the dependencies are listed incorrectly, it's fixed.

> Plus, the pyawn method requires a restart of the applet, as opposed to just clicking
> OK. I personally dislike restarts of AWN (which is what the average user would do, as
> opposed to removing/adding the applet) since I have to reenter passwords, set
> audio devices, and such.

I'm not opposed to changing the dialog so that the wiki button doesn't kill the dialog, the "OK" button turns into a "Try Loading it again" button, which just re-runs the function, and adding another button, "Cancel" (which just leaves the user with the infamous white line). I'm not wedded to the text of either button.

> Plus, if you add the disto packages, you can then add some sort of autodetection
> of distro to make life more simple for the user (I use Mepis but only Ubuntu and
> Fedora are listed here, or there are hundreds here, I'll never find Debian!).

I looked into detecting distributions and the auto-installation of dependencies when I first opened this bug. It is a *very* non-trivial thing to do reliably.

> Plus, it assaults the user with popups which is NEVER good.

Um, what? my function only raises one Gtk+ dialog, and if they click the wiki button, then the wiki link is opened in either a new tab or a new window, depending on the python version. I hardly see that as "assaulting".

[pavpanchekha (pavpanchekha)]

"""
I don't think it's the job of the applet developer to find out the exact dependencies for each and every distribution that their applet's users may run. It should be a collaborative effort, hence why it's in the wiki.
"""

On the other hand, removing a fairly long step (Possibly opening browser, which could take a while, opening the fairly slow wiki etc.) is worth it.

"""
I don't like the fact that you call the wiki "somewhere unknown". It's the official wiki, not some Joe Blogger's "HOWTO install Awn in three easy steps". Additionally, I don't exactly understand what you mean by "finding something unknownish". The exact package names for the distributions listed are named, and if someone reports that the dependencies are listed incorrectly, it's fixed.
"""

Its important to realize that since Hardy, most users will not know that there is a wiki or forum for awn, will get support from the ubuntu forums. You can't assume that the user had any idea that there is a wiki, definitely not that they installed from there.

"""
I'm not opposed to changing the dialog so that the wiki button doesn't kill the dialog, the "OK" button turns into a "Try Loading it again" button, which just re-runs the function, and adding another button, "Cancel" (which just leaves the user with the infamous white line). I'm not wedded to the text of either button.
"""

"""
I looked into detecting distributions and the auto-installation of dependencies when I first opened this bug. It is a *very* non-trivial thing to do reliably.
"""

Worst case, its possible to do a cursory check of whether apt-get is installed.

"""
Um, what? my function only raises one Gtk+ dialog, and if they click the wiki button, then the wiki link is opened in either a new tab or a new window, depending on the python version. I hardly see that as "assaulting".
"""
Anything that causes the user to make a decision NOW is bad. Such as popups. A hideable error is ignorable, a popup is not.

[moonbeam (rcryderman)]

"Its important to realize that since Hardy, most users will not know that there is a wiki or forum for awn, will get support from the ubuntu forums. You can't assume that the user had any idea that there is a wiki, definitely not that they installed from there."

I think a ubuntu-centric approach is incorrect. If this is done it needs to not make any assumptions about the distribution in question.

"Worst case, its possible to do a cursory check of whether apt-get is installed."

Once again... debian-centric.

"Anything that causes the user to make a decision NOW is bad. Such as popups. A hideable error is ignorable, a popup is not."

Give them a popup.

I more or less believe the hardy user argument is fallacious. I assume when the applets get packaged for hardy the dependencies will be done properly so that they are pulled in by the package manager when they install the applets. Assuming the packagers do things correctly (Hi gilir!) this python dependency checking will only be triggered when someone installs with a non-distribution approved method... in which case they should be pointed to the wiki.

[pavpanchekha (pavpanchekha)]

"""
I think a ubuntu-centric approach is incorrect. If this is done it needs to not make any assumptions about the distribution in question.
"""

That's not what I meant. I meant in general that awn will be, as time goes on, more and more often installed by package manager, by apt:// urls, or from rpm and deb sites, but not by our wiki. I don't propose anything special about ubuntu. It applies equally well to anyone on fedora or suse or debian or slackware or whatever other distro decides that AWN is ready for their repo. As soon as that happen, the infrastructure our project has created (forum, launchpad, wiki) is bypassed because installation and basic use does not require it.

Currently AWN Forum goes right to the Animation World Network's forum and AWN Wiki points to wikipedia disambiguation, then the old wiki, and then the new one. While ubuntuforums, or the fedora forums, or forums for any other distro do not have to be looked for. Hardy was an example, not a particular reliance on ubuntu or any other distro.

"""
"Worst case, its possible to do a cursory check of whether apt-get is installed."

Once again... debian-centric.
"""

Well, its a valid enough heuristic, and again, its nearly impossible to do exactly. In any case, at least there is the possibility of doing something more, as opposed to there being no such possibility. You can also do a search for Yum and guess at fedora, a search for... you get the idea. and make the text:

It seems you're using Ubuntu. If that is the case, please install the package python-feedparser.
[+] More distros

And the more distros expands to a list of all distros.

BTW, I use ubuntu in all the examples since I know the correct package names for it. Replacing all references to ubuntu with fedora, debian, slackware, gentoo, or others wouldn't change much.

"""
I more or less believe the hardy user argument is fallacious. I assume when the applets get packaged for hardy the dependencies will be done properly so that they are pulled in by the package manager when they install the applets. Assuming the packagers do things correctly (Hi gilir!) this python dependency checking will only be triggered when someone installs with a non-distribution approved method... in which case they should be pointed to the wiki.
"""

Soon as its in the repos, there will be more applets using it for two reasons:

1) Its easier to install awn, so more people are using it.
2) There is a fairly stable API that can be relied on - the one most distros are using.
Since Ubuntu and Fedora, which are the biggest distros (so I have heard) release within months of each other, there shouldn't be aversion change between and so a LOT of people are using the same AWN version (since the distros will go with the stable version, I'm guessing.)

And these applets will be installed not through the package manager, (I'm sure the packagers will do a wonderful job) but through gnome-look.org and such. Thus, dependancies will be out of our hands. Plus, these developers may also not have heard about the wiki (as guides based on other guides of AWN applets start sprouting up on the internet) and so may not update it for their applet.

[moonbeam (rcryderman)]

"That's not what I meant. I meant in general that awn will be, as time goes on, more and more often installed by package manager, by apt:// urls, or from rpm and deb sites, but not by our wiki. I don't propose anything special about ubuntu. It applies equally well to anyone on fedora or suse or debian or slackware or whatever other distro decides that AWN is ready for their repo. As soon as that happen, the infrastructure our project has created (forum, launchpad, wiki) is bypassed because installation and basic use does not require it."

A lot of work for someone.

"Well, its a valid enough heuristic, and again, its nearly impossible to do exactly. In any case, at least there is the possibility of doing something more, as opposed to there being no such possibility. You can also do a search for Yum and guess at fedora, a search for... you get the idea. and make the text:

It seems you're using Ubuntu. If that is the case, please install the package python-feedparser.
[+] More distros"

I really think this will require a large expenditure of effort. I might be wrong.

"And these applets will be installed not through the package manager, (I'm sure the packagers will do a wonderful job) but through gnome-look.org and such. Thus, dependancies will be out of our hands. Plus, these developers may also not have heard about the wiki (as guides based on other guides of AWN applets start sprouting up on the internet) and so may not update it for their applet."

That could happen.

I guess from my perspective I think providing a popup is a good thing when there is a missing dependency... I have no issues with being clever about resolving it. But, if being clever about it is not extremely close to 100% likely to resolve it, then they should get a popup. I also think the text (and url(s) ) in the popup should be easily tweaked by package maintainers so they can change it to point at their help forums if they so desire - and I think that should be encouraged.

[Julien Lavergne (gilir)]

In my packager point of view, I don't think installing python applets with the current system is a good way :
- you need to install them to /usr/lib or /usr/local/lib, not good for no compile thinks (should go to /usr/share)
- you can't uninstall them, or edit them because there are installed with root rights
- python don't need compilation like C, so don't need the same build system that C or Vala applets

The perfect way to go for me :
- add possibility to download and install python applet with awn-manager, like a deb repo but for awn applets.
- add depends somewhere (maybe the .desktop) and use policykit/packagekit or other tool to install missing depends.

For short term, packagers need to manage this depends. Others are people who test or develop AWN. So point to the official docs is not a bad idea :) And now, there is a warning in compilation for those depends. Or if it's not, it should be added.

[moonbeam (rcryderman)]

gilir,

"- you need to install them to /usr/lib or /usr/local/lib, not good for no compile thinks (should go to /usr/share)"

true enough.

"- you can't uninstall them, or edit them because there are installed with root rights"

Like most applications.

as a computer _user_ I have a really strong dislike of installing to the user home directory. It just means more maintenance... and I don't tend to have a lot of accounts. As a user I want these to be installed systemwide so I have the same functionality (and bugs) in all of my accounts. That's not to say local user installs are not useful and they definitely should be supported but... in general I do not like them.

It's like firefox... it's nice you can download and install extensions through the application but the problem, for me, is that they install in the user directory. I'd be really happy if there was an option to install system wide through gksudo.

Anyway, from a computer maintenance point of view I think system wide installs make life easier in most cases. At least for me.

[pavpanchekha (pavpanchekha)]

I don't suppose the applets can be packaged as EGG's? Though that has problems of its own. Don't know how easy that would be, am not too familiar with easy_install.

"""
add possibility to download and install python applet with awn-manager, like a deb repo but for awn applets.
"""

I suppose it wouldn't be too hard to implement, but this would mean:
1. A lot more work on the manager, which is already in need of updates
2. Cutting off all those users who have no internet (which, granted isn't as important)
3. Requiring a lot more work on the server half of this, whereas now we're letting others provide that.

Plus this introduces a lot more problems in terms of errors that could come up. Plus, replicating a system as complex as apt would be a major undertaking, best avaoided if possible (after all: stacks plugger depends on stacks, so does stacks trash, so we'd need to handle that.) Perhaps this could be done, but I don't see why it should be. In any case, the central question is how to handle dependancies in particular.

"""
add depends somewhere (maybe the .desktop) and use policykit/packagekit or other tool to install missing depends.
"""

I don't know how easy this would be to implement in practice, but it seems like a good idea. Again, though, this would leave the burden on the developer to provide package lists. Also, what happens if a system does not have package/policykit installed? I know that hardy should come with one of them by default, but other distros may not have them and anyway many people use old releases (compatibility, afraid to upgrade, support...)

[Green Dragon (great-wyrm-green-dragon)]

I am against supplying a link to the wiki instead of making the dependencies downloadable via Synaptic (or whatever is used).

[Mark Lee (malept)]

I guess I need to reiterate: determining a user's distro and invoking their package manager is a NON-TRIVIAL task to do programmatically. Non-trivial means that it's difficult to do. Packagekit is attempting to get this right, and it would be nice to use it so we don't have to have this discussion anymore, but it's still in development and not all (major) package managers are supported yet.

I should note that Awn has never been one that is very "backwards compatible", or any sort of "compatible", for that matter. It's taken me at least nine months to get desktop-agnostic to even be considered to be merged into trunk, and there's still some resistance. Additionally, Awn 0.3 (AKA Neil's work) will require the latest version of Gtk+, which will mean that a number of distro versions will be dropped (e.g., anything behind hardy, probably lenny+1, and F9).

[Green Dragon (great-wyrm-green-dragon)]

First off I am not a programmer, so...

Anyway, couldn't the code just be copied from another application that does this thing and made usable with awn? An application I can think of right off the bat is Amarok. If one does not have mp3 support and they try to play an mp3 in Amarok a message will appear telling them they can download mp3 support. If the user clicks the link Snyaptic loads up, the user enters their password, and it downloads. Couldn't the code for this in Amarok just be copied and put into effect with awn?

[Andrew Starr-Bochicchio (andrewsomething)]

@Green Dragon

You still have the issue of sorting out what distro the user is on and how to handle unsupported distros. I don't believe that Amarok its self does what you're talking about. It's done through Ubuntu's (I'm assuming that's what you use) codec installer. If you started Amarok on a different distro thtat won't necessarily happen.

[Green Dragon (great-wyrm-green-dragon)]

Although if it is downloaded specifically through the Ubuntu repository, it can have Ubuntu specific parts. I think this would always be a good option. People with Ubuntu deserve to be rewarded :P.

[Andrew Starr-Bochicchio (andrewsomething)]

Fix from desktop-agnostic merged into trunk by way of awn-core-testing

[pavpanchekha (pavpanchekha)]

Judging by recent activity, I'm guessing that the decision has been made to use the awn way and not the AWNLib method. Is this correct?

[Andrew Starr-Bochicchio (andrewsomething)]

New release: https://edge.launchpad.net/awn/0.2/0.2.4/

[Mark Lee (malept)]

Closing, as we have two different ways of doing it now (in Awn proper and in AWNLib). It's up to the applet developers to incorporate either method.