[aur-general] Rpc Info Order
Previously when using the Rpc interface info requests would always be returned in order of input but I realised this specific request [1] returns out of order. Is order a thing that was never guaranteed and just happened to be true in 99% of instances or is this a true bug? https://aur.archlinux.org/rpc/?v=5&type=info&arg[]=gstreamer0.10-good-plugins&arg[]=bin32-jre&arg[]=lib32-gstreamer0.10-base&arg[]=lib32-openssl098
Looking around a little more It seems to be a split package thing. Split packages always come before normal packages. I feel like something like this would be pretty common and found by now so I'm leaning on this not being a bug and just the way it is. On 17 February 2018 at 20:07, Morgan Adamiec <morganamilo@gmail.com> wrote:
Previously when using the Rpc interface info requests would always be returned in order of input but I realised this specific request [1] returns out of order. Is order a thing that was never guaranteed and just happened to be true in 99% of instances or is this a true bug?
On Sat, Feb 17, 2018 at 08:30:58PM +0000, Morgan Adamiec via aur-general wrote:
Looking around a little more It seems to be a split package thing. Split packages always come before normal packages. I feel like something like this would be pretty common and found by now so I'm leaning on this not being a bug and just the way it is.
On 17 February 2018 at 20:07, Morgan Adamiec <morganamilo@gmail.com> wrote:
Previously when using the Rpc interface info requests would always be returned in order of input but I realised this specific request [1] returns out of order. Is order a thing that was never guaranteed and just happened to be true in 99% of instances or is this a true bug?
Thankfully life is nice and you can just use jq to sort by any field.
$ curl -g ... | jq '[.results[]] | sort_by(.Name)' Alad
Yes there's a few easy ways around it, was just wondering if it's a bug or not before making a bug report. On 17 February 2018 at 20:52, Alad Wenter via aur-general <aur-general@archlinux.org> wrote:
On Sat, Feb 17, 2018 at 08:30:58PM +0000, Morgan Adamiec via aur-general wrote:
Looking around a little more It seems to be a split package thing. Split packages always come before normal packages. I feel like something like this would be pretty common and found by now so I'm leaning on this not being a bug and just the way it is.
On 17 February 2018 at 20:07, Morgan Adamiec <morganamilo@gmail.com> wrote:
Previously when using the Rpc interface info requests would always be returned in order of input but I realised this specific request [1] returns out of order. Is order a thing that was never guaranteed and just happened to be true in 99% of instances or is this a true bug?
Thankfully life is nice and you can just use jq to sort by any field.
$ curl -g ... | jq '[.results[]] | sort_by(.Name)'
Alad
On Sat, Feb 17, 2018 at 08:57:54PM +0000, Morgan Adamiec via aur-general wrote:
Yes there's a few easy ways around it, was just wondering if it's a bug or not before making a bug report.
Where is it specified in what order the RPC output should be? If there is such a place and the behavior you notice goes against it, it might be worth filing a bug report. Otherwise, sort the output in whatever way you like. Note: please stop top-posting. Alad
On 17 February 2018 at 21:04, Alad Wenter via aur-general <aur-general@archlinux.org> wrote:
On Sat, Feb 17, 2018 at 08:57:54PM +0000, Morgan Adamiec via aur-general wrote:
Yes there's a few easy ways around it, was just wondering if it's a bug or not before making a bug report.
Where is it specified in what order the RPC output should be? If there is such a place and the behavior you notice goes against it, it might be worth filing a bug report. Otherwise, sort the output in whatever way you like.
Note: please stop top-posting.
Alad
It's just the behaviour I had always observed and the existing code base I was working with was already making this assumption. The RPC documentation was pretty brief and didn't mention it so I thought it was worth a check. I'll go change the code so it does not assume any more.
participants (2)
-
Alad Wenter
-
Morgan Adamiec