Wanted to flag that the Doctor Drafts documentation suggests two different ways of installing Python3. And one of them at least doesn’t seem to be working for me. The install page on the web site links to a 2021 page recommending the official python.org installer, and specifically recommends against using homebrew. The diagnostic page that comes up when you run drdiag within Alfred links to an older post that describes using homebrew (and pyenv) and specifically recommends against using the python.org installer. I admit I am well out of my depth here, but these suggestions seem to be in contradiction with one another.
For my part, I used the python.org installer as recommended on the Doctor Draft web site install page, and while I can access Python3 from the terminal and run a print command to test it, Doctor Drafts commands still aren’t working for me, and drdiag tells me it can’t find Python3. Still troubleshooting that.
I have installed/uninstalled/reinstalled Python a handful of times in different ways. I got them all working by hook or by crook … eventually
The one I have personally had the most success with is the Homebrew and Pyenv approach.
What I might take a go at is putting together a set of instructions based on that to go on the site and then link off to other resources should people have any issues on their system.
The python.org installer did eventually work for me - there was a problem with my Xcode command line installation, apparently, because when I reinstalled that, drdiag found python3 and now the full suite of dr commands is functional.
v1.7.0 is now available. This includes a new way of triggering the Python-script-driven functionality. I’m hoping it will prove to be more resilient and allow for even easier set-up as a result.
There are new Python 3 installation instructions on the website (linked to if you have Python 3 issues found by drdiag. This is now run automatically if there is an issue running a Python script - giving what is in effect both useful and actionable information about an error.
There is also a new quick access checker (drpyver) for checking the version of Python that Doctor Drafts will attempt to use to run Python scripts. Mainly for my use in developing this change and testing various configurations that switched around my Python version.
I didn’t get any feedback on beta testing of this, so I’m going a little blind on something that has a lot of what ifs and caveats associated with it. I guess we’ll see how close I got as people start to pick up the update and use it.
It includes a fix as notified by@Richard_Cool, as well as a few additions to the diagnostics and a new option to copy a workspace’s URL to the clipboard.
I have also deprecated the Drafts beta related flows as Drafts beta testing on macOS is now managed via Testflight. Launching these will now take you to the beta programme page.
The new update includes explicit support for URL handlers (Alfred v5) on many of the external call triggers meaning you can call a big chunk of functionality from URLs. In addition, there is a fix for appending flows where a used UUID was not always being reset (and it should have been).
External Trigger objects can now optionally be run from the alfred: URL scheme
Because I have added this, this latest release is officially only compatible with Alfred v5, but anyone still on v4 is welcome to try it (I have not). You can alwsys download any release version from the links in the change log if you need to revert to the previous version.
To accompany the URL handling, I’ve also updated all the documentation of the flows based on external call triggers with example AppleScript code and URLs. The documentation is available on the website.
I have also updated the Drafts scripting (including beta) and user guide links used by some of the flows. These are maintained in separate online files, so these are also available to users on earlier versions - I just happen to have spent a bit of time doing all these housekeeping updates.
Enjoy the update, and of course, there is also more in the pipeline
v1.10.0 of Doctor Drafts was released at the weekend.
The main change is that the environment variables have been transitioned to user configuration options, so you’ll be able to more readily review and change these in Alfred 5. There are also some more behind the scenes changes.
That’s a little ambiguous. Are you saying that now you have followed the instructions that everything is working and so you no longer have the issue; or are you saying you followed the instructions and the diagnostics indicate everything is working but you still have the issue?
There is something odd looking in your output there. That page should look more like this:
You seem to be getting all sorts of output appearing on the web page that the shell script generate that you shouldn’t. Now, I am a little behind on my OS updates (I’m on 14.4.1), so maybe that’s something to do with it, but I would be surprised.
I do have some changes to apply to this workflow that could might help. I need to change a lot of scripts in it to use --no-rcs and then test it. I’ve done this for most of my other Alfred workflows, but Doctor Drafts is the biggest and most complex so I need a good couple of days to run it through. In the case of the other workflows, some of them also use Python and this has seemed to take out some edge cases causes by user configuration files such as .zshrc. If your problem is indeed ongoing that could be a cause, but it isn’t guaranteed to be. It would be worth checking through your config for anything that could interfere.
During my end of year break I have finally managed to sit down and get some changes and testing done on Doctor Drafts, so there’s a new version out for everyone to enjoy as we all head into 2025.
The -no-rcs option is now applied throughout and everything still seems to be working; do let me know if you find otherwise
The links to all the online information sites (accessed via drdoc, drscr, etc.) have been updated after being woefully out of date in many cases.
All of the keyword triggers are now customisable via the workflow settings. You can even blank them out if you find the range of options overwhelming; just be sure to keep the primary option (dr - though you can change that too) available, and you can then still get to everything via that rather than directly.
A missing keyword for one of the forum search types has been added. Everything was configured and documented, but somehow the keyword trigger never got added.
There’s a new keyword trigger and flow to open the configuration settings for the workflow.
A fair few documentation tweaks on the website (mainly corrections).
I’ve also updated a lot of the behind the scenes configuration that builds the website so it is using more up to date versions of things, and hopefully I don’t have to keep fixing the search a few times each year after this round of revisions.
While there are no big new features in this release I would like to encourage anyone who hasn’t taken a look yet at extending this workflow to have a read through the Use Cases section on the website, where you can get examples you can tailor for building your own custom workflows using Doctor Drafts as the base.
Most of the enquiries I get about the workflow end up being resolved by adapting one of the existing use cases, but I am always on the look out for new ones to add.
Omigosh. I started using Drafts a while back as my go-to notes app, partly because I use Obsidian, and Drafts integrates so nicely with the latter. Just today, my husband introduced me to Alfred. Love the app, and immediately started trying to figure out how I could use it with Drafts and LO AND BEHOLD, YOU HAVE ALREADY CREATED AN ALFRED WORKFLOW.
