Easier use of python venvs

[pSpitzner]

Hi @BenjaminOddou

thanks for this awesome workflow!

I just set it up, and it took me a while to figure out how to make it respect a local uv venv.

In the end, the solution for me was to:

• create a .venv in the workflow folder uv venv --python 3.12
• install pillow there uv pip install pillow
• edit the two api call scripts to include source .venv/bin/activate before calling python3

Easy enough, but I did not want to modify the workflow, so updates wont break the setup.
Maybe you want to the optional sourcing logic (and add a snippet to the readme that uv venvs are a good idea to keep things contained)

Why?

• Python via brew is a decent alternative since python3 is not shipping with macOS anymore, but...
• it gets hard to isolate things
• brew installs are pretty slow in comparison to creating uv venvs and installing pillow there
• uv venvs per workflow really seem very sensible to me, since workflows often have very differen requirements (maybe we pitch this idea as a suggest pattern to the alfted devs — they are always very helpful and welcome ideas!)

Thanks again,
p

[BenjaminOddou]

Hey @pSpitzner,

Thanks for your message. While I prefer using a venv configuration, it isn't the most user-friendly approach for non-technical users. Requiring the end user to run terminal commands can be frustrating. I could build an automation script, but it wouldn't comply with the Alfred Gallery guidelines, which prohibit scripts that download external dependencies (see their submission requirements).

[pSpitzner]

Hey hey,

thanks for the quick reply!

I totally agree, installing should not require users in terminals.
Having said that, im a technical user, and install took me some ~15 min (not due to the wf, but due to the mess around brew and python since py3 does not ship with macos anymore — and I really want to get rid of global installs).

Since a lot of peolpe are migrating to uv (which in many cases allows you to abandon brew), a bit of readme an an optional way to use a specified python would do the job.

Ive seen a neat convention in some workflows:
They create a variable to choose which python interpreter to use. Maybe such a setting would fit both requirements:

• default, use brew, try to figure this out as good as possible
• set custom py path, (absolute or relative to workflow)

Anyway, just a suggestion. I guess technical users might also find the issue and just hack it together themselves :)