pdi - Pacman database Informer 2.2

kittykatt · 2010-10-05 19:41:58

I'll update the PKGBUILD on the AUR now.

mangus · 2010-10-05 19:58:29

kittykatt wrote:

I'll update the PKGBUILD on the AUR now.

thanks very much

kittykatt · 2010-10-05 20:26:55

Updated to 2.0 in the AUR.

EnvoyRising · 2010-10-07 05:36:49

Use case: I want to see all non-testing packages installed. As of now, I have to manually select each one. If I were able to select more than one, I could view all non-testing packages at once.

mangus · 2010-10-10 09:07:44

EnvoyRising wrote:

Use case: I want to see all non-testing packages installed. As of now, I have to manually select each one. If I were able to select more than one, I could view all non-testing packages at once.

I took a look at that and found a lot of problems , trying to implement a qmenu with checkable dynamic actions and signals (as I would like to parse pacman.conf for real repos ,official or not, instead of using only official static ones)
with static entries it would be simplier but I came to the conclusion that if this is the only use case , I much prefer to implement an 'all but testing' entry in the combobox.
As my knowledge is limited, I found not trivial to put checkbox widgets in a qmenu like shown in your mockup and handle the listing that way.
Any hints or examples are welcomed , thanks

EDIT: while in few minutes I managed a listAllbutTesting working:

def listAllbutTesting(self):
          self.listWidget.clear()
          list1=os.popen("pacman -Q","r").readlines()
          print list1
          list2=os.popen("paclist testing","r").readlines()
          if not list2:
              self.textEdit.setText('Impossible to find Testing repository in pacman.conf,or no Testing packages installed.')
              self.statusbar.clearMessage()
              return
          print list2
          list3=list(set(list1)-set(list2))
          for i in list3:
              item = QtGui.QListWidgetItem(i.strip())
              item.setIcon(QtGui.QIcon('pixmaps/tgz.png'))
              self.listWidget.addItem(item)
          c=self.listWidget.count()
          self.statusbar.showMessage(str(c) + ' installed packages but Testing')

Last edited by mangus (2010-10-10 09:42:33)

EnvoyRising · 2010-10-14 17:14:46

I'm trying to look at the code right now, but I thought I'd report this:

 pdi
  File "main.py", line 111
    a=line.split(' ')[0].rstrip("\n")[1:-1]
                                          ^
TabError: inconsistent use of tabs and spaces in indentation

I'd suggest configuring your editor to replace tabs with spaces.

Anyways, investigating the checkbox thing, will report back once I have something

EnvoyRising · 2010-10-15 00:34:08

bleh, couldnt access site until now but im at work.

You can set a qactions checkable property to gegt a checkbox. IIRC the signal is called triggered or something. You would then need to modify the method that loads repos to accept mutiple repos. It mighgt allow for more flexibility if you leverage the model/view conceptsof qt.

i couldnt patch the code without severly changing the indentation so i opted not to, sorry

Update:
Patched the code to get an implementation of a menu with checkboxes, but the user experience degrades. As such the only way to not impact the user experience negatively is to have a list box instead of a combo box, which takes away from the streamlined look and feel. Looks like having presets in the combo box as you predicted earlier is a good idea. Perhaps "Official" for non-third party repos and "Stable" for anything not in testing are good additions.

Also, the use of QLists is unneccessary. You can instead use python lists.

Edit 2:

If you make the findRepos method actually return the list of repos, you can reuse that code to replace listAll as well as to achieve the allButTesting functionality:

No patches this time, just raw code.

change findRepos() to:

def findRepos(self):
          qlist= QtCore.QStringList('All')
          f = open('/etc/pacman.conf','r')
          for line in f.readlines():
             if line[0] == '[':  ## this may be ugly....
             a=line.split(' ')[0].rstrip("\n")[1:-1]
                 qlist.append(a)
          f.close()
          qlist.removeAt(1)  ###removes '[options]' from pacman.conf parsed with the repos
          qlist.append('Orphans - pacman -Qdt')
          qlist.append('Foreign - pacman -Qm')
                  qlist.append('List All But Testing')
                  return qlist

add the lines removed from findRepos to __init__:

def __init__(self,parent=None):
         ...
          qlist=self.findRepos()
          self.comboBox.addItems(qlist)
          self.comboBox.insertSeparator((self.comboBox.count())-2)
          ...

and clearAll:

    def clearAll(self):
          qlist=self.findRepos()
          self.comboBox.addItems(qlist)
          self.comboBox.insertSeparator((self.comboBox.count())-2)
          ...

At this point, it may seem as though I've made more work for you, but what follows is what will help you clean up some code.

change listRepo:

def listRepo(self,repo):
                  self.listWidget.clear()
                  self.textEdit.clear()
                  self.style()
                  self.textEdit_2.clear()
                  self.textEdit_3.clear()
                  self.textEdit_4.clear()

                  if repo == 'Orphans - pacman -Qdt':
                    self.listOrphans()
                  elif repo == 'Foreign - pacman -Qm':
                    self.listForeign()
                  else:
                    if repo == 'Stable':
                        repos = [i for i in self.findRepos()[1:-3] if 'testing' not in x]
                    elif repo == 'All':
                        repos = self.findRepos()[1:-3]
                    else:
                      repos = [repo]

                    for repo in repos:
                      for i in os.popen("paclist "+ str(repo),"r"):
                        item = QtGui.QListWidgetItem(i.strip())
                        item.setIcon(QtGui.QIcon('pixmaps/tgz.png'))
                        self.listWidget.addItem(item)
                    c=self.listWidget.count()
                    self.statusbar.showMessage(str(c) + ' ' + str(repo) +' packages')

Remove listAll all together.

I use a list comprehension to selectively exclude any repos that don't have "Testing" in their name from the results. I also implemented elifs so that you don't have to wait on each individual if statement to execute. Effectively, the 'All but testing' (stable) feature is implemented in 3 lines of code.

Actually, the code in listOrphans and listForeign is rather redundant, so they could be moved to listRepo and eliminated entirely.

I have the above changes implemented (except for the comment about orphans and foreign) if you are interested in a real patch. FYI, I followed your coding stlye as closely as possible.

Last edited by EnvoyRising (2010-10-18 16:14:33)

mangus · 2010-10-23 19:18:26

sorry for the delay , I was really busy in this days , not having time to look at this..
released versions of pdi will work pointing the interpreter to python2 instead of python as the result of the 'big python upgrade'.
I'm working for a python3 version reformatting the code with better indentation , and then I stumble on this
https://bugs.launchpad.net/ubuntu/+sour … bug/400826
It seems our pyqt package doesn't support python3 yet , and this is probably a packaging issue that devs have to deal, I'll probably open a bug in our flyspray if it's not already there.
@EnvoyRising
I haven't look at your patch yet but I'll do it soon trying to merge some , thanks

EDIT: and here it is:
https://bugs.archlinux.org/task/21439 (closed for duplicate)
https://bugs.archlinux.org/task/21422

Last edited by mangus (2010-10-23 19:45:39)

mangus · 2010-10-24 16:31:43

@EnvoyRising
Can you test this a little:
http://pastebin.com/0t7SyGLX

I've merged your listRepos and clean up the code with better indentation I hope, removing listorphans and listForeign too..
I also used a python list instead of qlist..I have some code for a configuration file to manage the systray
but it will come later , now I need some testing here to ensure the core is still ok
python2 is used as pyqt with python3 is 'officially' broken atm
thanks for hints

mangus · 2010-10-24 17:09:29

bump for version 2.0.1 , for python2 compliance.

kittykatt · 2010-10-24 19:02:44

If you need me to upload a new PKGBUILD, post a link to one and let me know.

mangus · 2010-10-24 19:20:45

kittykatt wrote:

If you need me to upload a new PKGBUILD, post a link to one and let me know.

It's in the first post , if you wanna take a look , thanks!

kittykatt · 2010-10-25 00:47:39

Updated PKGBUILD in AUR.

EnvoyRising · 2010-10-25 15:22:22

Works fine. Indentation still needs some work, but I presume it's a work in progress, right? Might I suggest refering to the official style guide for python code?

By the presence of the subprossess module import statement I presume you already know you can replace os.popen with subprocess.Popen or similar? I think I saw partial code on the bottom, which probably means this is also a work in progress.

Otherwise fantastic. My only other suggestion would be to change "'testing' not in i" to "'testing' and 'unstable' not in i" (gnome-unstable and kde-unstable repos)

mangus · 2010-10-25 16:44:35

EnvoyRising wrote:

Works fine. Indentation still needs some work, but I presume it's a work in progress, right? Might I suggest refering to the official style guide for python code?
By the presence of the subprossess module import statement I presume you already know you can replace os.popen with subprocess.Popen or similar? I think I saw partial code on the bottom, which probably means this is also a work in progress.
Otherwise fantastic. My only other suggestion would be to change "'testing' not in i" to "'testing' and 'unstable' not in i" (gnome-unstable and kde-unstable repos)

Do you want me to read docs? oh nooou...jokin' here , I hope I configured my editor correctly now...
BTW do you know package-query? Do you think it might have something useful for us? for example it returns the repo list so no need
of parsing...
thanks
edit:
http://pastebin.com/uYDYixSC
indentation rework, use of subprocess , 'unstable' with 'testing'.

Last edited by mangus (2010-10-25 21:22:06)

EnvoyRising · 2010-10-26 16:01:39

list is a reserved word, so shouldn't be used as a variable name. Actually, variable names should be descriptive in general, but that's another topic all together.

I've reworked a couple of things without altering your coding style. Changes made:
- renamed list to repo_list
- changed del to list.pop()
- removed \ from strings (quotes within parenthesis will be concated)
- added Orphan, Foreign, and Stable to the original repo_list and added others via insert instead of append

I haven't looked at package-query yet

Actually, using package query would allow you to replace pacman-contrib and some other code.

-List packages in a repo:
package-query -Sl <repo name>

-List all installed packages
package-query -Sl

-List Foreign
package-query -Qm

Question is, being that you would have to rewrite a lot of code, do you think the trouble is worth what you'd gain? Personally, I think you'd get more use out of it than pacman-contrib (using more functions)

Last edited by EnvoyRising (2010-10-26 16:31:54)

tawan · 2010-10-26 19:54:01

Very useful tool I can see how this could grow into a manager i.e. right click to uninstall package and so on.

Along with pacgraph I used this tool to slim my system a lot. Nice work.

mangus · 2010-10-27 09:18:45

@EnvoyRising: Merged , thanks. Finally I've added the code for a configuration file , for disabling the systrayicon and for the option to start pdi minimized(with the systray activated oc). You can have a look at what we can call 'beta' now , here
I agree for what you say about package-query , and I'd add that it's not in a 'official' repo and I wouldn't make a AUR package
as a deps. I really would like to retrieve somewhat from what repo a single local package comes from, but this info isn't stored
in the local database, it seems . It would be nice in the 'All' option have a second column with the place of origin.

@tawan: Thanks , but I don't think pdi will ever become a package handler, because it wouldn't be the 'arch way' and I don't want
to hurt someone else database . Upgrading and removing packages is up to you, root , and CLI.

@All: If someone knows some pacman tricks to find or retrieve some kind of useful informations about the local db to show,
let us know and we can take a look
cheers

Last edited by mangus (2010-10-27 09:21:33)

SanskritFritz · 2010-10-27 11:16:07

I also want to express my thanks for pdi.

kittykatt · 2010-10-27 13:34:05

mangus wrote:

I really would like to retrieve somewhat from what repo a single local package comes from, but this info isn't stored
in the local database, it seems . It would be nice in the 'All' option have a second column with the place of origin.

Well, how do most of the package managers/helpers do it? How does pacman itself do it? Yaourt? Packer? Bauerbill? Clyde? I'd start here and then try to adapt it to python.

I've just noticed that gpacman in the AUR is also written in Python. As is gtkpacman in the AUR. I personally have not tried either of these before, but I'd check and see if they have support for categorizing all the "local" packages.

EnvoyRising · 2010-10-27 16:44:14

mangus wrote:

. It would be nice in the 'All' option have a second column with the place of origin.

You can do that with pacman.

In bash:

for package in $(pacman -Qe); do pacman -Ss $package; done

The python version of the above is much longer, so it's worth just feeding that into Popen.

If you just want the repo name and the package name without having to parse, you can use package-query and the format switch, instead of manually parsing the results in python. (also in bash):

for package in $(pacman -Qe); do package-query -Ss $package -f %r/%n; done

If the above format is unacceptable, rather than splitting the string in pythong to reformat, I'd suggest looking at the other formatting options available for package-query. Only reason you should need python is if you want to split the elements to use seperately.

SanskritFritz · 2010-10-27 18:44:28

The packages themselves dont hold any information about the origin. All you can do (and this is what most helpers do) is list the repo where the package is available now, and assume that you have installed it from that particular repo. In my case this is often not the case, for example I had fcron installed from AUR, but later it was moved to community. At that moment, "pacman -Ss fcron" said, the package is available in community, hence the helpers all assumed, I installed it from there, and since the package got deleted from AUR, there was no way to determine that I have installed it from AUR. Maybe pacman.log could give a hint, but I doubt this could be automatized.

mangus · 2010-10-27 19:10:17

while I found the output of 'package-query -Q' very interesting,I found some issue there...example:
I've installed only a package from testing , abs. With testing repo in pacman.conf the output of package-query -Qi is:

┌─[mangus@tao64][20:57]
└─[~]-> package-query -Qi abs                                                                                                                            
testing/abs 2.4.1-1 [0,12 M]

and that's correct, but if I remove testing from pacman.conf:

┌─[mangus@tao64][20:57]
└─[~]-> package-query -Qi abs                                                                                                                                    
extra/abs 2.4.1-1 [0,12 M]

incorrect, because the installed package comes from testing.

The fact is ,that information is not stored in the local db so all this are workarounds in this particular cases, that leads to errors.
Probably this is not a so relevant information, but it would be nice to have in some cases.
That info should be stored in the desc file of every package but that's probably not possible because the same package can change repo more times, so you'll never know.

EDIT:
and SanskritFritz said the same thing while I was typing.

Last edited by mangus (2010-10-27 19:12:25)

SanskritFritz · 2010-10-27 19:24:35

Hmm, actually this could be considered a bug in pacman, as it actually outputs errorneus information here. - UPDATE: sorry, I checked, and it is not pacman that outputs wrong info.

I even had cases when there were more packages with the same name in different repos. I investigated bauerbill-s code and found that bauerbill simply outputs the first repo found as origin.

Last edited by SanskritFritz (2010-10-27 19:26:34)

EnvoyRising · 2010-10-28 02:03:06

The true origin of a package is rather irrelevant isn't it? I mean if a package exists in one location, then gets moved to another, then trying to download it from its "origin" would fail. What's more important is where the package can be found, IMHO, which the above command accomplishes. Besides, usually version numbers in testing differ than the ones in stable repos.

The only real exception to that I could see is if you build a package from abs. In that case, it may be worth renaming the package and adding a 'provides' in order to keep track of packages built manually, assuming some special patching/build options were neccessary.

Alternatively, the only way to track the "origin" of a package is to capture the output of pacman and other helpers during install to glean the download location.

Arch Linux

#26 2010-10-05 19:41:58

Re: pdi - Pacman database Informer 2.2

#27 2010-10-05 19:58:29

Re: pdi - Pacman database Informer 2.2

#28 2010-10-05 20:26:55

Re: pdi - Pacman database Informer 2.2

#29 2010-10-07 05:36:49

Re: pdi - Pacman database Informer 2.2

#30 2010-10-10 09:07:44

Re: pdi - Pacman database Informer 2.2

#31 2010-10-14 17:14:46

Re: pdi - Pacman database Informer 2.2

#32 2010-10-15 00:34:08

Re: pdi - Pacman database Informer 2.2

#33 2010-10-23 19:18:26

Re: pdi - Pacman database Informer 2.2

#34 2010-10-24 16:31:43

Re: pdi - Pacman database Informer 2.2

#35 2010-10-24 17:09:29

Re: pdi - Pacman database Informer 2.2

#36 2010-10-24 19:02:44

Re: pdi - Pacman database Informer 2.2

#37 2010-10-24 19:20:45

Re: pdi - Pacman database Informer 2.2

#38 2010-10-25 00:47:39

Re: pdi - Pacman database Informer 2.2

#39 2010-10-25 15:22:22

Re: pdi - Pacman database Informer 2.2

#40 2010-10-25 16:44:35

Re: pdi - Pacman database Informer 2.2

#41 2010-10-26 16:01:39

Re: pdi - Pacman database Informer 2.2

#42 2010-10-26 19:54:01

Re: pdi - Pacman database Informer 2.2

#43 2010-10-27 09:18:45

Re: pdi - Pacman database Informer 2.2

#44 2010-10-27 11:16:07

Re: pdi - Pacman database Informer 2.2

#45 2010-10-27 13:34:05

Re: pdi - Pacman database Informer 2.2

#46 2010-10-27 16:44:14

Re: pdi - Pacman database Informer 2.2

#47 2010-10-27 18:44:28

Re: pdi - Pacman database Informer 2.2

#48 2010-10-27 19:10:17

Re: pdi - Pacman database Informer 2.2

#49 2010-10-27 19:24:35

Re: pdi - Pacman database Informer 2.2

#50 2010-10-28 02:03:06

Re: pdi - Pacman database Informer 2.2

Board footer