autocomplete on abra recipe upgrade is slow #567

Open
opened 2025-06-04 17:15:29 +00:00 by 3wordchant · 8 comments
Owner

Not quite a "bug" but it does cause a little friction.

Autocomplete on recipe names is much slower than on app names. Probably because app autocomplete is based on listing files but recipe autocomplete is based on parsing JSON. Maybe there's nothing we can do but if it's possible to optimise it'd be awesome

CC @trav

Not quite a "bug" but it does cause a little friction. Autocomplete on recipe names is much slower than on app names. Probably because app autocomplete is based on listing files but recipe autocomplete is based on parsing JSON. Maybe there's nothing we can do but if it's possible to optimise it'd be awesome CC @trav
3wordchant added the
bug
label 2025-06-04 17:15:29 +00:00
Owner

Yeh I would love to speed this up also, I routinely get frozen waiting for this...

I think it might be doing some network activity in there somewhere....

Definitely something to improve!

Yeh I would love to speed this up also, I routinely get frozen waiting for this... I think it might be doing some network activity in there somewhere.... Definitely something to improve!
decentral1se self-assigned this 2025-07-08 09:59:25 +00:00
decentral1se added the
red abya yala
label 2025-07-08 10:02:24 +00:00
decentral1se added this to the Abra "next" project 2025-07-08 10:06:51 +00:00
Member

When autocompleting recipe names, it first ensures the recipe catalogue is up to date. This makes it slower. We have the following options:

  1. Don't ensure at all
  2. Only ensure exists and not ensure up to date
  3. Only ensure on the first autocomplete invocation. When doing abra recipe upgrade <tab><tab> It only ensures once
When autocompleting recipe names, it first ensures the recipe catalogue is up to date. This makes it slower. We have the following options: 1. Don't ensure at all 2. Only ensure exists and not ensure up to date 3. Only ensure on the first autocomplete invocation. When doing `abra recipe upgrade <tab><tab>` It only ensures once
Author
Owner

Thanks @p4u1 ! 🙏

  1. Don't ensure at all
  2. Only ensure exists and not ensure up to date
  3. Only ensure on the first autocomplete invocation. When doing abra recipe upgrade It only ensures once

#3 seems good, but maybe the most complex to implement – and it might be hard to avoid it being "first autocomplete invocation per shell".

#1 seems easiest but most fragile.

I am leaning towards #2 – but am I correct that we don't have a specific command to sync the recipe catalogue?

Thanks @p4u1 ! 🙏 > 1. Don't ensure at all > 2. Only ensure exists and not ensure up to date > 3. Only ensure on the first autocomplete invocation. When doing abra recipe upgrade <tab><tab> It only ensures once #3 seems good, but maybe the most complex to implement – and it might be hard to avoid it being "first autocomplete invocation _per shell_". #1 seems easiest but most fragile. I am leaning towards #2 – but am I correct that we don't have a specific command to sync the recipe catalogue?
Member

option 3 is actually quite easy to implement. This would also be the safest option, but it would still be slow on the first each time you run abra recipe upgrade

also you are correct that there is no command to sync the recipe catalogue. With option two would then need that i guess..

option 3 is actually quite easy to implement. This would also be the safest option, but it would still be slow on the first <tab> each time you run abra recipe upgrade also you are correct that there is no command to sync the recipe catalogue. With option two would then need that i guess..
Author
Owner

option 3 is actually quite easy to implement. This would also be the safest option, but it would still be slow on the first each time you run abra recipe upgrade

OK! Out of interest, how are you thinking abra would know whether to refresh the catalogue?

> option 3 is actually quite easy to implement. This would also be the safest option, but it would still be slow on the first each time you run abra recipe upgrade OK! Out of interest, how are you thinking abra would know whether to refresh the catalogue?
Owner

Thanks for thinking this one through! It might make sense to do a abra catalogue sync and then make all catalogue operations local only? Then if you're missing something you expect to be there, you run a sync?

This is all the places that recipe.ReadRecipeCatalogue() is called, so it's quite significant and contributes to slowing things down. Also, we tried to get around this before by adding a true/false argument if it should only do an offline operation.

pkg/recipe/recipe.go|449 col 15| GetRecipeMeta
cli/recipe/list.go|22 col 23| init
cli/recipe/version.go|31 col 26| init
pkg/autocomplete/autocomplete.go|57 col 22| RecipeVersionComplete
cli/catalogue/catalogue.go|157 col 26| init
cli/internal/validate.go|23 col 23| ValidateRecipe
cli/recipe/fetch.go|88 col 28| init
cli/updater/updater.go|260 col 22| getAvailableUpgrades
pkg/autocomplete/autocomplete.go|41 col 22| RecipeNameComplete
pkg/lint/recipe.go|396 col 25| LintHasPublishedVersion
pkg/recipe/recipe.go|414 col 20| VersionsOfService

One optimisation could be to check if go-git has any way to remotely query the last modified value of the catalogue repository? Then you would know potentially faster if you need to actually do a full pull or not. I'm not sure this is provided and if it would offer a better experience in the "need to pull" case.

Not sure on this one!

Thanks for thinking this one through! It might make sense to do a `abra catalogue sync` and then make all catalogue operations local only? Then if you're missing something you expect to be there, you run a sync? This is all the places that `recipe.ReadRecipeCatalogue()` is called, so it's quite significant and contributes to slowing things down. Also, we tried to get around this before by adding a `true`/`false` argument if it should only do an offline operation. ``` pkg/recipe/recipe.go|449 col 15| GetRecipeMeta cli/recipe/list.go|22 col 23| init cli/recipe/version.go|31 col 26| init pkg/autocomplete/autocomplete.go|57 col 22| RecipeVersionComplete cli/catalogue/catalogue.go|157 col 26| init cli/internal/validate.go|23 col 23| ValidateRecipe cli/recipe/fetch.go|88 col 28| init cli/updater/updater.go|260 col 22| getAvailableUpgrades pkg/autocomplete/autocomplete.go|41 col 22| RecipeNameComplete pkg/lint/recipe.go|396 col 25| LintHasPublishedVersion pkg/recipe/recipe.go|414 col 20| VersionsOfService ``` One optimisation could be to check if `go-git` has any way to remotely query the last modified value of the catalogue repository? Then you would know potentially faster if you need to actually do a full pull or not. I'm not sure this is provided and if it would offer a better experience in the "need to pull" case. Not sure on this one!
decentral1se moved this to In Progress in Abra "next" on 2025-08-12 05:23:00 +00:00
Owner

My proposal is option 2. I don't understand how option 3 would know how to only do it once and I am not much of a fan of doing some sort of bookkeeping to remember this. Please do let us know though if there is some way to manage it. Then, I would go for:

  • Add abra catalogue sync to update catalogue
  • Ensure catalogue exists but don't pull latest

This way, it's less automatic but should be faster for the day-to-day use. If you can't find it in the auto-complete, you know you should abra catalogue sync. And the implementation should also make sure it pulls in the local recipe listing too (which I think it does).

My proposal is option 2. I don't understand how option 3 would know how to only do it once and I am not much of a fan of doing some sort of bookkeeping to remember this. Please do let us know though if there is some way to manage it. Then, I would go for: * Add `abra catalogue sync` to update catalogue * Ensure catalogue exists but don't pull latest This way, it's less automatic but should be faster for the day-to-day use. If you can't find it in the auto-complete, you know you should `abra catalogue sync`. And the implementation should also make sure it pulls in the local recipe listing too (which I think it does).
Owner

RFC: #604

RFC: https://git.coopcloud.tech/toolshed/abra/pulls/604
Sign in to join this conversation.
3 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: toolshed/abra#567
No description provided.