[Enhancement] Native search that spans both repos and AUR (again) #644
Comments
|
I can add a |
|
Thank you for all these issue reports by the way, they are a great help. |
|
I have an initial form of it working. |
For whatever it's worth, as a long-term user of |
|
Thanks for your ongoing support :) As for wide search, as a subflag it was fairly cheap to add. If people need it for scripting purposes or otherwise, it's there. Today I'll be tackling the Git issues. |
First of all, I'm sorry, but dealing with other issues has nothing to do with this topic.
Arch's own treatment is that AUR packages should be built from scratch with bare hands via
I'm afraid, you got it wrong. I don't need any pacman/aura scripting. It's only for my daily administration. Look at my typical scenario: I just heard about some software called, say "Deadbeef", I want to try it, I don't want to browse the web looking for package information, I have no business getting into nasty details of packaging. So I just type in Oh, and here my ultimate argument punch line: you won't have separate flag for removing AUR packages, wouldn't you? |
|
If you already have an alias for the search, then you're free to alias the new subflag as well. The output with the new subflag is exactly as you're describing: |
Are they sorted by name including prefix? I found it odd to showing AUR packages in front of [official] repositories; especially since you case so much about Arch's treatment. I know I may sound as devil's advocate in this discussion, but if anything, whenever there is a pre-made binary package available from official repos — I would definitely give it a priority. Otherwise, that sounds reasonable and might work out just good enough. Idk why you chose |
|
|
|
At this rate, the most reliable way to figure out all free letters is to check the source code itself. |
|
I keep the manpage up to date, I think As for the crappy |
|
Not sure whether it's been reported already, here's one more case of confusing inconsistency: % auras () {
aura -Ss $* && aura -As $*
}
% auras qt quick 3d
extra/qt5-quick3d 5.15.1-1 (qt qt5)
Qt module and API for defining 3D content in Qt Quick
Invalid argument `quick'
Usage: aura ((-A|--aursync) PACKAGES | (-B|--save) | (-C|--downgrade)
([-u|--uninstalled] | PACKAGES) |
(-L|--viewlog) | (-O|--orphans) | (-P|--analysis) |
(-V|--version) | --languages | --viewconf |
((-D|--database) PACKAGES | (-F|--files) | (-Q|--query)
[[PACKAGES]] |
(-R|--remove) PACKAGES | (-S|--sync) [PACKAGES] | (-T|--deptest)
PACKAGES |
(-U|--upgrade) PACKAGES)) [--log-level debug|info|warn|error]The first search result was correctly narrowed down by all three search terms. Second search blew up with an error. Note that the function function search() {
aura -Ss $1 && aura -As $1
} |
|
The AUR search endpoint doesn't quite work the same way, unfortunately. While a search for I think I have a way around that issue, though. Trying it now. |
|
Oh, that sucks :( Search page is prerendred, so I guess there's not much we could do — other than manually computing intersection of individual search results. Which is horrible - but not so bad - idea after all, better than showing Usage output anyway. Who's to say that aura must stick only to what JSON API provides us with? |
|
Exactly, and that's what I've done: |
|
And the final result: |
|
Now, I've just updated aura, and the issue is its Autocompletion in zsh also suggests only second variant at the end of |
|
Would be co cool to have that as an ultimate system upgrade command. |
|
Ugh, snap it!
Still not legit substitute for |
|
|
|
I'm kinda not much into philosophy, I'm more on the "get things done" side. Guess I still can do a fork, which would be a nightmare to maintain. |
|
I understand and appreciate your concern here. It's actually that same motivation that made me "draw the line" all the years ago about what Aura is and isn't. From Aura's perspective, it's a feature, not a bug, that Perhaps this doesn't match your personal workflow, and so I see how the separation would feel like an inconvenience. "Why do I have to do two commands to get one thing done?" And once again it's Aura philosophy, it's a "ground rule", that updating repo packages and updating AUR packages are in fact two very different things. The Arch folks don't approve of AUR-compatible package managers because they make doing a "dangerous thing" (i.e. building AUR packages) too easy. And by having |
Summary
Aura needs a native support, e.g. special combination of flags, to search both repos and AUR in one shot.
Description
Native support for a 'wide' search has been an issue for a long time. It has been discussed in 2013 (#88), but I am not happy with the resolution. Since then, the officially suggested way to search both locations is no define a shell function which would call
auratwice, passing the same search term to two different modes of operation, namely-Asand-Ss.I don't like the proposed solution, because
.${SHELL}rc... and all that only because you guys didn't come up with a reasonable combination of flags.
Besides, as noted in #639 ,
aurafails with a flashy error message and a non-zero status code whenever it cannot find search matches in the repositories.Also, the line drawn between repos and AUR operations in
aurais unnecessary thick. Like, if I ever have to do either one task or another, but never both at the same time. It may be the right way conceptually, but for a regular user it introduces additional complexity. Honestly, I think the main reason here is the possible complications in code logic, and that it was decided to lift that complexity onto end-users. The general question of this paragraph is: Why AUR packages are considered so second-grady?Alternatives
Pacaur searches everywhere with
-Ssoptions, and installs from anywhere with-Soption. Very convenient, recommend, 5/5.Yay "extends pacman operations":
Version
The text was updated successfully, but these errors were encountered: