Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 275567 - webapp-config has a horrible nightmarish and completely unusable interface!
Summary: webapp-config has a horrible nightmarish and completely unusable interface!
Status: RESOLVED CANTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Gentoo Web Application Packages Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-27 06:47 UTC by Navid Zamani
Modified: 2009-11-25 19:00 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Navid Zamani 2009-06-27 06:47:14 UTC
Ok, I confess: I am very angry!

I'm trying to get webapp-config do update my webapps for half an hour now, and even if you would mix the UI of Gimp with the quality of IE’s Trident engine, the ease of use of vi PLUS emacs, and add Clippy to it, you would not get to the level of madness that this interface presents!

I just want to update all my apps. So what would be the obious thing to do?

# webapp-config -U
> * Fatal error: You need to specify at least the application you would like to handle!
> * Fatal error(s) - aborting

Allright, it’s obvious, but I will do that:

# webapp-config -U all
> * Fatal error: You did not specify which version to handle.
> * Fatal error:  Use "/usr/sbin/webapp-config --help" for usage
> * Fatal error(s) - aborting

Now it’s getting silly. Let’s try this:

# webapp-config -U all all
> Traceback (most recent call last):
>   File "/usr/sbin/webapp-config", line 44, in <module>
>     main()
>   File "/usr/sbin/webapp-config", line 41, in main
>     config.run()
>   File "/usr/lib/python2.5/site-packages/WebappConfig/config.py", line 1167, in run
>     ws.reportpackageavail()
>   File "/usr/lib/python2.5/site-packages/WebappConfig/db.py", line 708, in reportpackageavail
>     available = self.packageavail()
>   File "/usr/lib/python2.5/site-packages/WebappConfig/db.py", line 684, in packageavail
>     if not wrapper.package_installed('=' + self.package_name()):
>   File "/usr/lib/python2.5/site-packages/WebappConfig/wrapper.py", line 86, in package_installed
>     t = portage.db[portage.root]["vartree"].dbapi.match(packagename)
>   File "//usr/lib/portage/pym/portage/dbapi/vartree.py", line 334, in match
>     origdep, mydb=self, use_cache=use_cache, settings=self.settings)
>   File "//usr/lib/portage/pym/portage/__init__.py", line 7188, in dep_expand
>     return portage.dep.Atom(prefix + expanded + postfix)
>   File "//usr/lib/portage/pym/portage/dep.py", line 499, in __call__
>     instance = super(_AtomCache, cls).__call__(s)
>   File "//usr/lib/portage/pym/portage/dep.py", line 530, in __init__
>     raise InvalidAtom(s)
> portage.exception.InvalidAtom: =null/all-all

YAY. It’s “working”. *cries*.
So what else? Maybe I can update each version separately, by using a for loop. What does webapp-config offer, to find out the apps installed?

>    --list-installs, --li
>                        List all current virtual installs for <application>.
>                        Use * for the package name and/or version number to
>                        list more thanone package / version of a package.
>                        Remember to include the * in single quotes to stop
>                        your shell from expanding it first!!

Nice. Let's try this:

# webapp-config --li '*' '*'
> 

Nothing? No output? Ok, maybe this way:

# webapp-config --li '*'
> 

WTF? And this? Should not work, but can’t hurt to try…

# webapp-config --li
> /var/www/intranet.server.tld/htdocs/wiki
> /var/www/intranet.server.tld/htdocs/phpmyadmin
> /var/www/intranet.server.tld/htdocs/phppgadmin

Finally. But *where are the versions*?
Ok, at least I have the apps dirs, so webapp-config should be able to update them. Let’s try this:

# for W in $(webapp-config --li); do webapp-config -U "$W"; done
> * Fatal error: You did not specify which version to handle.
> * Fatal error:  Use "/usr/sbin/webapp-config --help" for usage
> * Fatal error(s) - aborting
> * Fatal error: You did not specify which version to handle.
> * Fatal error:  Use "/usr/sbin/webapp-config --help" for usage
> * Fatal error(s) - aborting
> * Fatal error: You did not specify which version to handle.
> * Fatal error:  Use "/usr/sbin/webapp-config --help" for usage
> * Fatal error(s) - aborting

Damn. and even with a added »-d«, it does not work. (I got tons of stack traces, while trying variants of the above. About invalid atoms.) It expects the app name and the version. Which »--li« *does not provide*.
There’s no need to continue trying this. 

So to update a webapp, I have to *guess* the name and version of the apps in the directories that »--li« provides?? Seriously? There is no easy way? Like, you know, the first one I tried? A way that *actually is not criminally insane*??

Sorry that I am so evil right now. I have no good word left after this half hour. I hope you can see this as a valuable user experience, to improve this thing.

I, for one, would, if I could, nuke that thing from orbit, encrypt it with a one-time-pad that I throw away afterwards, and then shoot into a black hole. It’s the only way to be sure. ^^

But I guess you may prefer a total rewrite of the interface, and a renaming, to not confuse those poor souls even more, who already got used to it. :)

Reproducible: Always

Steps to Reproduce:
See description.
Actual Results:  
See description.

Expected Results:  
See description.

See description.
Comment 1 Hugo Mildenberger 2009-11-25 14:36:48 UTC
(In reply to comment #0)

> I, for one, would, if I could, nuke that thing from orbit, encrypt it with a
> one-time-pad that I throw away afterwards, and then shoot into a black hole.
> It’s the only way to be sure. ^^
> 
> But I guess you may prefer a total rewrite of the interface, and a 
> renaming, to not confuse those poor souls even more, who already got 
> used to it. :)

I'm in particular amused that you even distrust one-time-pads when it comes to webapp-admin ... Having looked closer into the code, I also think this software appears more like a prototype merily able to demonstrate the concept of a two phased installation. I encountered several severe bugs during my experiment to write an ebuild using webapp.eclass, and thus webapp-admin, and I still didn't have filed them all.

 
Comment 2 Navid Zamani 2009-11-25 15:25:51 UTC
(In reply to comment #1)
> I'm in particular amused that you even distrust one-time-pads when it comes to
> webapp-admin ...

In case this really was an answer to my comment:
And I am really amused by how in the world you got to the topic of one-time-pads. How has that anything to do with *anything* here? ^^
Are you sure you commented on the right bug?

If I would care, I think I could design a better interface for webapp-config in a couple of minutes. :)

But as this bug is pretty old, and I had already forgotten about it, by completely boycotting webapp-config and doing it manually with a small script, I don’t care anymore.

It’s just… those poor souls who are trying to use it.

Marking it as CANTFIX, since I don’t think there is anything fixable in it, and I stopped caring. Just throw it in the trash and start over, using someone’s own self-made workaround scripts. :)
Comment 3 Hugo Mildenberger 2009-11-25 19:00:38 UTC
(In reply to comment #2)

> If I would care, I think I could design a better interface for 
> webapp-config in a couple of minutes. :)

Don't be so angry. My intention was to second you on the impression that this program needs to be rewritten. Having a well designed user interface ready would be a good starting point. So hic rhodos, hic salta.