auryea and aurora - simpler AUR frontends

EnvoyRising · 2010-01-02 00:58:31

synorgy wrote:

whoops...I may or may not have simply copied the import statements from your version >_>

I'll take the hit for this one then. Those two were there while I was trying to profile some code, lol.

Anyways, I just realized that you can save yourself a little work/typing by replacing all instances of getstatusoutput with getoutput.
something like:

raw = getstatusoutput("some command")[1]

Would become:

raw = getoutput("some command")

Of course you would have to change the import statement.

synorgy · 2010-01-02 04:41:35

I was under the impression that getoutput() was being removed in 3.0 and I was trying to future-proof as well as I could. Seems I was wrong and it's getstatus() that is being removed. I'll work on changing those now. Expect a new commit sometime later tonight.

EnvoyRising · 2010-01-02 06:23:58

I had to read it a couple of times myself, lol. That's why I delayed in posting the suggestion.

synorgy · 2010-01-09 20:26:15

On my end, aurora occasionally has issues downloading a package. Has anyone else noted this? I'd like to blame the issue on my crappy internet connection, but I've also noticed that yaourt has no issues (or I did before I uninstalled yaourt).

EnvoyRising · 2010-01-10 03:39:49

No idea. I would write a try/catch block to catch 404/403 errors to see if that was the issue. With urlretrieve, it's a bit contrived but doable. Actually, this is one of the reasons I prefer urllib2's eror handling.

Now that I think about it, it might be worth checking out slurpy's code and compare how it handles downloading files.

Last edited by EnvoyRising (2010-03-28 14:42:23)

synorgy · 2010-03-26 15:18:18

Well, I've dusted off the code for aurora and I'm continuing to work on it again. In the works now are small updates:
1) Aurora will no longer allow you to run as root (since makepkg complains about it later in the build process)
2) Rudimentary support for downloading the PKGBUILD and supporting files only (without building) (I still have a bit of logic to work out here. The question is 'How do I deal with a situation like 'aurora -G opera' which brings in multiple results. For the moment I'm simply telling the user to refine their query, but that seems...mean. I should probably present the same menu I show for a search, but that means some more separation in the functions so that I'm not repeating myself)
3) Correctly moves through options presented and dies if multiple update options are given (-U, -G, -S can only be used one at a time and this checks for that.)
4) ???
5) profit.

Any ideas?

EDIT: Added #3 (since I just did it...)

Last edited by synorgy (2010-03-26 15:41:55)

Gen2ly · 2010-03-28 03:16:02

Looks good. I've been hoping to try it out, hoping ot get a chance. Looks like a different syntax is being used for pacman. Is this correct? Could you explain the reasoning behind that?

synorgy · 2010-03-28 03:50:17

Gen2ly: Yes - I'm using different syntax than pacman does. The reasoning for this is twofold; 1) I find the default pacman options oddly cryptic. They do a good job most of the time, but some of the combinations I find strange. This isn't nearly as much of a reason as 2) I'm using optparse.OptionParser to handle arguments (or flags or options or whatever you want to call them) and I can't find a decent way to handle multi-letter arguments (such as -Syu, for instance.) Thinking about it now, I could just use regexs, but python's implementation of them is rather terrible from what I hear.

Do you have a problem with the different syntax? If it's a 'hot item', I suppose I could migrate to the pacman syntax. In my defense, this does MUCH less than pacman and the simpler syntax seems to suit it better.

I'm looking over the code right now to make sure none of my debugging code is still actively running and then I'm going to push it to bitbucket.

EnvoyRising · 2010-03-28 14:41:09

synorgy wrote:

Gen2ly: Yes - I'm using different syntax than pacman does. The reasoning for this is twofold; 1) I find the default pacman options oddly cryptic. They do a good job most of the time, but some of the combinations I find strange. This isn't nearly as much of a reason as 2) I'm using optparse.OptionParser to handle arguments (or flags or options or whatever you want to call them) and I can't find a decent way to handle multi-letter arguments (such as -Syu, for instance.) Thinking about it now, I could just use regexs, but python's implementation of them is rather terrible from what I hear.
Do you have a problem with the different syntax? If it's a 'hot item', I suppose I could migrate to the pacman syntax. In my defense, this does MUCH less than pacman and the simpler syntax seems to suit it better.
I'm looking over the code right now to make sure none of my debugging code is still actively running and then I'm going to push it to bitbucket.

If you use callbacks then you can detect options that are side-by-side quite easily without regexes. See section 15.4.4.9 in the optparse documentation: http://docs.python.org/library/optparse … -callbacks

synorgy · 2010-03-29 14:20:57

EnvoyRising: Yes, I'm using callbacks to call functions for search, update and grab but, unless I'm wrong, the problem is that I'd have to set up optparse options for every possible permutation of the option string (for instance, since -Su and -uS are the same, I'd have to account for both - even better is -Syu, -Suy, -ySu, -yuS, -uSy, and -uyS). Don't get me wrong - it wouldn't be terribly difficult to handle, but the syntax I've chosen is rather simple and to the point, in my opinion and unless 'proper' syntax handling would increase adoption and use I've decided not to change it. (Especially with Clyde coming out before long, and it being a MUCH cleaner solution - using libalpm rather than calls to pacman)

I swear I'm pushing it to the repo today >_<

synorgy · 2010-03-29 16:04:22

Changes pushed to the bitbucket repository. Again here is the link.

EnvoyRising · 2010-03-29 16:23:41

synorgy wrote:

EnvoyRising: Yes, I'm using callbacks to call functions for search, update and grab but, unless I'm wrong, the problem is that I'd have to set up optparse options for every possible permutation of the option string (for instance, since -Su and -uS are the same, I'd have to account for both - even better is -Syu, -Suy, -ySu, -yuS, -uSy, and -uyS). <snip>

Very true about clyde (in fact, I confess that I am using it). I'd imagine this is at least a good learning process though. Plus, if memory serves correctly this is strictly an AUR helper?

As for the permutation problem, what about splitting the string then using if/in keywords?. Something sort of like:

seperate_values = values.split()
if 'y' in seperate_values:
  ..
elif 'u' in seperate_values:
  ..

I would agree that a unique syntax would be better in this case since the work-to-program-adoption ratio is probably declining with the release of bauerbill and clyde.

BTW, this PEP (argparse) is being adopted for the next python release, which will allow for more flexible argument options.

synorgy · 2010-03-29 17:23:41

In all honesty, unless someone else does it - I really don't see myself implementing different syntax. You're idea would work, but the way I see this working is that each option would set a variable and then I'd have to go back to check through which variables != None (or are false) and calling a function based on those results. In other terms: CBA

I do like the idea of argparse though and I'll be keeping up with it. I must admit to not following the PEP's NEARLY as closely as I should.

In regards to this being a learning process, you're right. I'm using it personally at the moment and I'm basically writing it for myself and only for myself. (This is another reason for me being reluctant to change the syntax - I frankly think pacman's syntax for arguments is horrid.) And yes - I have no intentions of extending aurora to handle anything more than the AUR. However, I currently call pacman to get lists of packages and the like. For instance, I call pacman -Qme to get a list of all packages that are installed, but not in any repo to hand to the upgrade() function. I could do this with pylibalpm, but the documentation for it is horrendous and it seems like it's out of date to boot.

EnvoyRising · 2010-03-29 18:01:12

In fact, elifs wouldn't work. They should all be ifs. Would be nice if there were a libalpm binding in python. Suppose you could do like kiwi and write your own

Gen2ly · 2010-03-30 04:31:14

synorgy wrote:

... different syntax? If it's a 'hot item', I suppose I could migrate to the pacman syntax. In my defense, this does MUCH less than pacman and the simpler syntax seems to suit it better.

Use whatever you think is best, of course. My reasoning is that users may not be too eager to learn a new systax. Perhaps, EnvoyRising already covered this though, though adoption could be seemless writing your own syntax may be more appeailing and have a fresh context. Please, write the program as best you see fit, pacman was done such a way years ago.

Kiwi · 2010-03-30 04:36:11

EnvoyRising wrote:

In fact, elifs wouldn't work. They should all be ifs. Would be nice if there were a libalpm binding in python. Suppose you could do like kiwi and write your own

There is/was (at least one). But last I tried it it fails miserably and I am not sure if it is updated or not. The svn might be, but the non-svn version on AUR is definitely not functional.

The one I am thinking of is Pyalpmm.

synorgy · 2010-03-30 15:40:56

I tried looking at pyalpmm, but it seems to be too much work for little gain. I could certainly optimize the areas where I would utilize plalpmm quite a bit more (even without utilising pyalpmm) but, in all honesty, aurora is rather quick as it stands now. In the future, I might consider it - but I think that if it gets to that point, I've experienced quite a bit of feature creep and should consider trimming things down in other ways.

That being said - is there any functionality that is critically missing from aurora currently? At the moment, I'm fresh out of ideas. The only real limitation to these ideas is 'wrapping' pacman or expanding into handling the default repositories. Pacman does a rather stellar job of this already - aside from my mentioned problems with the syntax.

synorgy · 2010-04-10 17:12:33

Just modified aurora to support selecting multiple packages from -S output. If anyone wants to test this, it'll be commited to bitbucket before long. I want to test a bit more before I upload it - I'm not sure I entirely trust the way I did it >_>

Arch Linux

#26 2010-01-02 00:58:31

Re: auryea and aurora - simpler AUR frontends

#27 2010-01-02 04:41:35

Re: auryea and aurora - simpler AUR frontends

#28 2010-01-02 06:23:58

Re: auryea and aurora - simpler AUR frontends

#29 2010-01-09 20:26:15

Re: auryea and aurora - simpler AUR frontends

#30 2010-01-10 03:39:49

Re: auryea and aurora - simpler AUR frontends

#31 2010-03-26 15:18:18

Re: auryea and aurora - simpler AUR frontends

#32 2010-03-28 03:16:02

Re: auryea and aurora - simpler AUR frontends

#33 2010-03-28 03:50:17

Re: auryea and aurora - simpler AUR frontends

#34 2010-03-28 14:41:09

Re: auryea and aurora - simpler AUR frontends

#35 2010-03-29 14:20:57

Re: auryea and aurora - simpler AUR frontends

#36 2010-03-29 16:04:22

Re: auryea and aurora - simpler AUR frontends

#37 2010-03-29 16:23:41

Re: auryea and aurora - simpler AUR frontends

#38 2010-03-29 17:23:41

Re: auryea and aurora - simpler AUR frontends

#39 2010-03-29 18:01:12

Re: auryea and aurora - simpler AUR frontends

#40 2010-03-30 04:31:14

Re: auryea and aurora - simpler AUR frontends

#41 2010-03-30 04:36:11

Re: auryea and aurora - simpler AUR frontends

#42 2010-03-30 15:40:56

Re: auryea and aurora - simpler AUR frontends

#43 2010-04-10 17:12:33

Re: auryea and aurora - simpler AUR frontends

Board footer