Tracking: issues with VSCode extension find-latest-etl-step

[pabloarosado]

Add here any issues you find while using the VSCode extension find-latest-etl-step.

Known issues

• It is not properly ignoring files from .gitignore. If you type, e.g. package you'll see that it lists files from .venv. For this reason, I had to hardcode ignoring certain folders, like data/. But there must be a way to properly take .gitignore into account (or even better, VSCode configuration, to also ignore archive folders).
• It is slow. It takes a second (on my computer) to open. Maybe once files in .gitignore are excluded, it will be come faster.

[Marigold]

Re-posting from here

Nice! I spent some time (actually, too much time...) trying to get searches like "meadow cherry" to work, but apparently, QuickPick doesn’t support fuzzy matching, and I couldn’t find a way to hack it. I think it should be possible to sort the results not just by date, but also by channel.

(It took me a while to figure out how to run the extension in development mode. If anyone wants to develop this further and hear about my experience, feel free to reach out.)

[pabloarosado]

Nice! I spent some time (actually, too much time...) trying to get searches like "meadow cherry" to work, but apparently, QuickPick doesn’t support fuzzy matching, and I couldn’t find a way to hack it. I think it should be possible to sort the results not just by date, but also by channel.

Thanks @Marigold, I also tried making the "meadow cherry" case work, but I also gave up after a while. In any case, just typing "cherry", seeing the list of latest "cherry" steps, and moving or and down to find the meadow step, is better than our current situation (where we hit cmd+P, type "meadow cherry" and see multiple versions). I think it's easier to navigate channels than versions. Maybe sorting by channel could help, but I think currently it's alphabetical order, which puts garden first (which is what we need most of the time).

To me, the main issue with the extension is that it's a bit slow (~2-4 seconds to start). I thought the issue was that it's scanning too many things, even some that should be ignored (like gitignored folders and archives). But I didn't look into it.