vitor

@evanfuchs That one is being handled by the original author and has already been rewritten, as you’ve seen in the original thread. Please don’t ask for ports of such Workflows, the original author should always be the first contact. Official fixes are preferred.

There is no system Python. /usr/bin/python3 is a shim which gets you to install the Developer Tools which ship with that older version. Don’t wait for it to be updated, because there’s no clue when or if that will happen. If you really need a higher Python version, recommend installing via Homebrew and set export PATH="/opt/homebrew/bin:/usr/local/bin:${PATH}". Other Python 3 developers do it, and it’s better than not having access to the Workflow.

@Travis Schmeisser See the Updated Third-Party Python 2 Workflows GitHub page. It explains the situation, links to instructions on regaining access to Python 2 and includes a fixed version of this Workflow.

@CWM See the Updated Third-Party Python 2 Workflows GitHub page. It explains the situation, links to instructions on regaining access to Python 2 and includes fixed versions of Case Converter and others. @bwbecker It is trivial to invoke Python 3. Save your script inside the Workflow with a proper shebang (#!/usr/bin/python3) and call it as an External Script as the Language. Or use /bin/zsh as the Language and call your script with /usr/bin/python3 SCRIPT_NAME. You were never limited by the languages in the dropdown, you can easily use anything on your system.

Until yesterday, probably. But with the release of Monterey 12.3 and kernel deprecations, Dropbox will start using the File Provider API and that means you can’t have the directory just anywhere. There may still be a way to share it, but keep in mind to do your experiments with the new version (still in beta, and pretty broken) so you don’t end up developing a system you’ll have to abandon a few weeks down the line.

When asking for help with a Workflow, please upload it somewhere as we can’t properly help you without access to it. Debugging can already be hard with access to the code, and you’re only providing a description and screenshots. There are multiple places where your code or Workflow setup may be going wrong. Without looking at it we’re shooting in the dark. See the Reporting Problems with Workflows topic for an overview on building effective reports.

@charlie-brise See the Updated Third-Party Python 2 Workflows GitHub page. It explains the situation, links to instructions on regaining access to Python 2 and includes a fixed version of this Favorites Workflow.

Never saw that happen. Is this right as you click the icon to open it, without having pressed Clear? Click once in the bug icon to close it and stop logging, then click it again to reopen and restart logging.

@Klaus Follow the official guide and this will work again.

@cands Check https://github.com/vitorgalvao/custom-alfred-iterm-scripts for an up-to-date iTerm2 script.

No, that would not work because Python 2 and 3 are different. Also no. The thread is for requests, there’s no point in reading it all. All you need is to follow the guide to reinstall Python 2 then install this updated version.

That should be fixed if you download it again, as it got an update today.

That one is already there. You have to check the GitHub repository for the full list. It also includes links to general guidelines on the fixes. Welcome. Please redownload it (same URL) and try again, as I just did further tweaks. I agree. But that takes time. And we also have to think of the non-coders who find themselves with broken tools and need a workaround. This solution is a stop-gap, not the end goal. See my other comment for a more complete answer. Added. That’s not a Python problem. Maybe you need to update the regex in the Workflow Environment Variable or do another thing. As per the top post: “this is only for Python 2 Workflows which break on Monterey 12.3 and above due to the Python 2 removal. If a Workflow stops working for any other reason, contact the author as usual”. Added.

That is not correct. You have to follow the whole guide and you’ll end up with Python in the correct location—which depends on your CPU architecture—to be used by these updated Workflows. No, don’t do that! There is a reason macOS stops you and the guide doesn’t suggest it: so you don’t shoot yourself in the foot. Even if you got it to work by forcing it, you’d be introducing things in a way macOS doesn’t expect and could mess up unrelated apps on your system. That won’t work either. You’re only considering Python installations via Homebrew on Apple Silicon, which ignores a huge percentage of users. Plus, it wouldn’t fix cases where the whole path isn’t included. The current guide and workaround are good. This was not a rush job, it has been in place and working for weeks. It was thought out and tested to be the most efficient and simple way to provide a working installation for most people. That is also incorrect. It’s fine that you don’t know these things, we all have to learn, but please don’t confuse users. If you don’t know, it’s harmful to others to contradict the official instructions. Those have been studied, tested, and improved from a thorough understanding of the problem.

It absolutely is. Plenty of them. Converting Workflows to Python 3 is considerably more work, thus takes way more time and requires a lot of testing just to reproduce what the Workflow did. Plus I dislike Python, so I don’t use it much and am not up-do-date with all the language features. Converting a ton of Workflows I don’t use from one language I dislike to another language I dislike wouldn’t be a pleasant or productive use of time. If I were to take on these conversions, there wouldn’t be time to do all the ones people are asking for. And even if there were, not all developers continue to be active to accept a pull request, meaning forking the Workflow and maintaining something I didn’t start. Disadvantages all around. It’s way more beneficial and makes way more sense for me to cast a wide net and provide the stop gap solution for most things to work again in the short-term. That allows others (like yourself with this Workflow) the time to develop the long-term ports which will eventually replace the temporary fixes I’m posting. The GitHub repo is explicit: The ideal scenario is one where that repo is no longer necessary. In the meantime, its existence eases the transition.

@glawrie See the Updated Third-Party Python 2 Workflows GitHub page. It explains the situation, links to instructions on regaining access to Python 2 and includes a fixed version of this Google Authenticator Workflow.

@psifertex See the Updated Third-Party Python 2 Workflows GitHub page. It explains the situation, links to instructions on regaining access to Python 2 and includes a fixed version of the Video Conferences Workflow.

@cvallera See the Updated Third-Party Python 2 Workflows GitHub page. It explains the situation, links to instructions on regaining access to Python 2 and includes a fixed version of this Outlook Search Workflow.

@lutefish See the Updated Third-Party Python 2 Workflows GitHub page. It explains the situation, links to instructions on regaining access to Python 2 and includes a fixed version of the Zothero Workflow.

Added. Editing the list isn’t very useful, because your changes won’t propagate to other people and they may not have whatever runtime you’ve added. It could cause hard-to-diagnose problems when sharing Workflows. Save your script inside the Workflow with a proper shebang (#!/usr/bin/python3) and call it as an External Script as the Language. Or use /bin/zsh as the Language and call your script with /usr/bin/python3 SCRIPT_NAME. You were never limited by the languages in the dropdown, you can easily use anything on your system.

It can’t. No software can, not the way you’re describing it. An app can’t simply inject its functionality inside another. This is the way. It’s the responsibility of apps to provide the hooks for third-parties to automate them. Some have a lot, some have none. Electron apps are particularly bad. Consider JXA. Being JavaScript, the skills you learn will be more useful in other contexts and you’ll find more resources for doing generic things. As explained above, this (again, in the way you described it) does not depend on Alfred. But from your examples, it seems like what you want can be mostly covered by a Menubar Search Workflow. Further, you can also just connect a Keyword to a Dispatch Key Combo and your first use case is also taken care of, no coding necessary, no complex integrations, done in a few seconds, and perfectly customisable.

Alternatively, copy the text to the clipboard and read it from there in the Run Script. Or, and this should be more convenient for this specific use-case, always normalise whatever text is passed-in. That would have the side-effect of fixing cases where the input is decomposed.

Short answer: bundle the dependencies. Lower the need to rely on the user’s environment. Long answer is below. With apologies to @Y1ng for having this long post in your Workflow’s thread. If you prefer, I can split these to another. What specifically worries you in that scenario? Is it the extra size? I just downloaded it to a temporary directory with dependencies and it came to just under 20MB. Granted, that isn’t small, but is it worse than the alternative? Consider your case under the multi-python scenario in my previous comment. You ask a user to pip3 install audible-cli and they now have it under a Python that is managed by pyenv. But because (let’s imagine) the Workflow is assuming a Homebrew Python installation, it doesn’t pick it up and appears broken. What do you do then? You can refine your instructions to specify a Homebrew Python needs to be used, but considering a multitude of possible setups and that the path to a Homebrewed Python changes depending on architecture, you’re now spending half of the “About” from your Workflow explaining technical details which are irrelevant to most. Or you can have a Workflow Environment Variable where users add a custom Python path, and now you need to do a bunch of checks to ensure it exists, and how to react when it doesn’t, and the Python path is now dynamic and your code is harder to maintain. Or you can make your Workflow 20MB larger. What’s the best option? It depends. What do you value most? What do you believe the users of your Workflow value most? How close to your ideals can your current level of skill take you? How do different goals correlate? Is a 1MB increase in file size worth it for a program 100 times faster? What about 100MB for something 1.5 times faster? What about 20MB for extra convenience? How do you even measure convenience? There is always a tradeoff. Your goal is to identify and pick the best one for your situation. Let’s keep exploring your specific case from a size perspective. Python is popular. If every Python Workflow included a full runtime—even if it were small—the duplication would lead to considerable wasted bandwidth and space (including in the user’s cloud hosting, for synced settings). But what about audible-cli, how likely is it that a user of your Workflow already has it installed, for another Workflow or in general? If they’re more likely to not have it (seems likely), is the extra size worth skipping the hassle of having to set it up? For under 20MB, I’d say yes; if it were 500MB, I’d say no. But even that is relative. How much of a hassle are you saving? Will a user not use your Workflow because it’s hard to setup? Will another not use it because its file size is too big? Both can be true. Which of those weighs more? Which choice will make a better Workflow for most people? Which one will make a better Workflows for yourself, one that you’ll continue to have fun developing and be proud to offer support for, which will in turn be better for users? There are answers to all of these questions. Though yours may be different than mine and they may change with time. Apologies for the length of the post. Given more time I’d have made it shorter and all that, but it’s dinner time. Have a nice evening.

You don’t. That paragraph applies in general, like installing it for yourself. If it’s for a Workflow, follow the first paragraph: bundle the package with the Workflow instead of asking the user to install it. That is significantly easier for users because they don’t have anything to setup and is beneficial to you because you know what version is used. It should be something like /path/to/python -m pip install --target "/CUSTOM/DIRECTORY/PATH" "PACKAGE_NAME" and then using export PYTHONPATH="/CUSTOM/DIRECTORY/PATH" before calling your script to ensure the package is available. Not really. You can try to guess but that doesn’t give you guarantees. A user may have, at the same time, /usr/bin/python3 (from the developer tools), /opt/homebrew/bin/python3 (installed as a dependency for another Homebrew package), and ~/.pyenv/shims/python3 (version-managed with pyenv). They may have only wanted (and directly use) the last one, but the others exist nonetheless (cue XKCD). You want to avoid that, for the benefit of both users and yourself. Extra manual steps you require, especially technical ones, increase your support burden. You should either use /usr/bin/python3 directly (macOS will prompt the user to install it if they don’t have it, and that’s done in two clicks) or require a Homebrew-installed Pyhton and use that path (not directly, use export PATH="/opt/homebrew/bin:/usr/local/bin:${PATH}" due to the different Homebrew locations). @Y1ng Since you’re just calling python, this point is particularly relevant. Starting next week, with the release of macOS Monterey 12.3, that will no longer be available. Yes, you shouldn’t be using Python 2 anymore. Or anything below 3.6, for that matter.

You must’ve renamed them. Judging by the naming pattern, via @deanishe’s script which I’m pretty sure was published to the forum years ago.