Does not work on macOS 12.3
willemml opened this issue · comments
macOS 12.3 beta 4 removes the built in Python 2.7 binary causing this workflow to break.
This workflow will need to be updated to support Python 3 if it is to be used on versions of macOS above 12.2.
For anyone who has upgraded to 12.3 and has not found an alternative yet I created a very hacky workaround for this using pyenv. I have created a release package for ease of use, make sure to read the updated README or just the new section.
Awesome work, @willemml! 👏
Thank you!
I wonder do you have immediate plans to update the workflow for python 3 support?
I personally do not have plans to update it to python 3 in the near future, I did a little bit of work on it a couple weeks ago but found that the dependency tree was quite deep, but I might try again later if I have time (this could be months from now because I already have it working even with the suboptimal pyenv method).
I couldn't make it work for some reason, even after installing everything according to the READMEs.
Did some of you run into this error message?
@matkovsky For me it was few things that didn't quite work and I needed to fix them.
First, the path to pyenv python was incorrect in my case.
Second, in workflow.py I improved the code, instead of inserting username manually I changed the code to
username = os.getlogin() PYTHONEXECUTABLE = '/Users/' + username + '/.pyenv/versions/pypy2.7-7.3.6/bin/python'
This way it works on every mac for me - home and work machines with different usernames.
Third, cPickle is Python 2 not 3, so it should be called in Python 2, otherwise it breaks.
Hey @CaptainMalReynolds if you could PR that to my repo, or just let me know and I will add it myself, that would be great, and another thing I would be to automatically determine (or have an option selected on install) the location of then pyenv executable. I will try to find a quick solution for this.
I made some more changes that should hopefully fix the problems people have been having, (implemented a slightly different version of what CaptainMalReynolds did and then also using it in the workflow scripts).
And I again uploaded a "release" https://github.com/willemml/alfred-convert/releases/tag/v3.7.3
@willemml Perfect, this works great, thanks for your quick fix and all the work you put into this. :)
Still got the problem:
[01:27:07.539] Logging Started...
[01:27:10.302] Convert[Script Filter] Queuing argument '1 usd'
[01:27:10.330] Convert[Script Filter] Script with argv '1 usd' finished
[01:27:10.334] ERROR: Convert[Script Filter] Code 127: .
http_proxy=
https_proxy=
/Users/alexanderkim/Library/Caches/com.runningwithcrayons.Alfred/Workflow Scripts/B8FF5C8D-7FC2-4AA9-8E9F-DB6C825EBE3B: line 5: /Users/alexanderkim/.pyenv/versions/pypy2.7-7.3.6/bin/python: No such file or directory
@avxkim could you please run ls /Users/alexanderkim/.pyenv/versions/? This is a different issue from the other one I just fixed.
@avxkim could you please run
ls /Users/alexanderkim/.pyenv/versions/? This is a different issue from the other one I just fixed.
/Users/alexanderkim/.pyenv - doesn't exist on my machine.
brew ls | grep python shows:
python@3.10
python@3.9
That is because you need to install pyenv, please read the README in my PR.
followed your readme and now it works, thanks.
Nice work, thanks.
Since your fork has no issue section I'll post here.
- You can use
$HOMEinstead of/Users/$(whoami). - A fixed version seems a little cumbersome; I assume there's a way, e.g.
pyenv versions | grep 2.7 | head -n1, to get what's installed, but that's one invocation each time the workflow is run.
Since your fork has no issue section I'll post here.
Oh neat, I didn't realize that was disabled by default... I have enabled it for future use.
You can use
$HOMEinstead of/Users/$(whoami).
Only reason I didn't do this is because some other environment variables were not working and all of the macOS systems I have used had whoami installed.
A fixed version seems a little cumbersome; I assume there's a way, e.g.
pyenv versions | grep 2.7 | head -n1, to get what's installed, but that's one invocation each time the workflow is run.
Yeah this should be fixed, I guess I should try to find a better way of doing that... I only did it this way because it was simplest and I wanted to avoid slowdowns. I am also not sure how Alfred workflow variables work (this is my first time making/modifying advanced workflows, and using pyenv), so maybe there is a way of doing it when the workflow is added to avoid adding delay. Maybe invoke a bash script that handles reading a file to get the path of the pyenv version and if file not found then use grep to find it and write to file? There is probably a better way of doing it.
You can use
$HOMEinstead of/Users/$(whoami).Only reason I didn't do this is because some other environment variables were not working and all of the macOS systems I have used had
whoamiinstalled.
At least you can trust $HOME.
Yeah this should be fixed, I guess I should try to find a better way of doing that... I only did it this way because it was simplest and I wanted to avoid slowdowns. I am also not sure how Alfred workflow variables work (this is my first time making/modifying advanced workflows, and using pyenv), so maybe there is a way of doing it when the workflow is added to avoid adding delay. Maybe invoke a bash script that handles reading a file to get the path of the pyenv version and if file not found then use grep to find it and write to file? There is probably a better way of doing it.
Thought of that too, something like if [ ! -f python2 ]; then ln "get_python2()" python2; fi; ./python2 convert.py "$1". I'll dig that later.
I wanted to ask you if adding additional currencies is broken now as well? For example, I added BNB in the list of currencies in active_currencies.txt but it doesn't recognize it anyway no matter what I do. I also added my API key. Is there something I'm missing here?
And on a side note, convinfo was broken as well because of the python path being incorrect now, so if I point it to the pyenv one same as in other places it works.
Thanks for this. I sync my Alfred preferences in Dropbox between two machines that have different usernames. What would you recommend for dynamically pulling that?
EDIT: I used os.environ['USER'].
Hi @willemml - I'm getting this error:
[17:39:37.762] Convert[[Script Filter](alfredpreferences:workflows%3Eworkflow%3Euser.workflow.12FEF95E-CBE0-4384-97CD-E2C3176190FA%3E1E12C11D-30DB-44A8-AD75-F5BE7F2DA451)] Queuing argument '128 mph' [17:39:37.780] Convert[[Script Filter](alfredpreferences:workflows%3Eworkflow%3Euser.workflow.12FEF95E-CBE0-4384-97CD-E2C3176190FA%3E1E12C11D-30DB-44A8-AD75-F5BE7F2DA451)] Script with argv '128 mph' finished [17:39:37.782] ERROR: Convert[[Script Filter](alfredpreferences:workflows%3Eworkflow%3Euser.workflow.12FEF95E-CBE0-4384-97CD-E2C3176190FA%3E1E12C11D-30DB-44A8-AD75-F5BE7F2DA451)] Code 127: . http_proxy= https_proxy= /Users/michaelbaldwin/Library/Caches/com.runningwithcrayons.Alfred/Workflow Scripts/5C6F6243-E965-41B1-A154-653CE538BD63:5: no such file or directory: /opt/homebrew/bin/pyenv /Users/michaelbaldwin/Library/Caches/com.runningwithcrayons.Alfred/Workflow Scripts/5C6F6243-E965-41B1-A154-653CE538BD63:7: no such file or directory: /opt/homebrew/bin/pyenv /Users/michaelbaldwin/Library/Caches/com.runningwithcrayons.Alfred/Workflow Scripts/5C6F6243-E965-41B1-A154-653CE538BD63:9: no such file or directory: /opt/homebrew/bin/pyenv /Users/michaelbaldwin/Library/Caches/com.runningwithcrayons.Alfred/Workflow Scripts/5C6F6243-E965-41B1-A154-653CE538BD63:11: no such file or directory: /opt/homebrew/bin/pyenv
Is this because pyenv got installed to the wrong folder or something?
pyenv install pypy2.7-7.3.6 michaelbaldwin@Michaels-MacBook-Air-2 ~ % pyenv install pypy2.7-7.3.6 pyenv: /Users/michaelbaldwin/.pyenv/versions/pypy2.7-7.3.6 already exists continue with installation? (y/N)
@kenanmike yes, it is most likely that you have the wrong pyenv path set.
@CaptainMalReynolds I do not know if adding more currencies is broken as I have never tried adding another. Also it's strange that convinfo wasn't working for you because it was for me, maybe I didn't update it to use dynamic paths...
@kenanmike which version are you using? As far as I know the latest release on my fork fixes this, it looks like you are using my original "fix".
Working for me now. You're a beast, thanks!
For anyone who has upgraded to 12.3 and has not found an alternative yet I created a very hacky workaround for this using pyenv. I have created a release package for ease of use, make sure to read the updated README or just the new section.
Thanks for your efforts. Unfortunately I don't use Homebrew, I won't use Homebrew, and I don't recommend anyone use Homebrew.
pip refuses to install pyenv and unfortunately Macports doesn't have pyenv, which means I would need to install it the old fashioned way (earrrrrrrn it?) or port it myself.
Before I go down that road, could this be made to work with virtualenv?
@hexadecagram I used Homebrew because it was handy (I already used it) and this was quickly hacked together.
I know very little about Python but from what I know of quickly reading some SO threads on virtualenv I do not think it would work for this purpose. It looks like virtualenv just isolates the installation of Python packages but does not allow you to use specific versions of Python. But if someone knows otherwise do let me know!
@hexadecagram Please note that pyenv is by design not installed through pip. See https://pypi.org/project/pyenv/.
You could add it to MacPorts ports, if you want it.
It should be trivial to work in a pyenv created virtualenv - instead of the hardcoded Python version, use ~/.pyenv/versions/VENV_NAME/bin/python.
@willemml No need to explain yourself, just realize that changing ownership of /usr/local from root:wheel to really anything else is a horrible security risk, especially if it is a login user's account.
Sounds like you already considered virtualenv and the thing to do would be to port pyenv to Macports. I'll see if I can get to that in the near future but I have bigger fish to fry for the time being.
@bnoctis I will give your recommendation a shot, thanks.
No need to explain yourself, just realize that changing ownership of /usr/local from root:wheel to really anything else is a horrible security risk, especially if it is a login user's account.
FWIW, homebrew does not do that (anymore). It uses /opt/homebrew
Taking a step back:
Is it really worth to jump through all these hoops just to avoid upgrading the source to python3?
I am not a python person but what's the complexity of that upgrade?
That discussion feels more forward oriented.
FWIW, homebrew does not do that (anymore). It uses
/opt/homebrew
@tcurdt That's actually very good news! Now, the million dollar question: can I install Homebrew alongside MacPorts? I would not mind having both installed at all. I just had a look myself. Evidently, /opt/homebrew is a Mac Silicon thing whereas /usr/local is still the default for Mac Intel (which is what I am on for the time being).
Apparently you can change the install location to whatever you like but it seems Homebrew still clings to the "1 user is all you need" mentality and rids us of that "terrible inconvenience" of having to use sudo. Thanks guys, I had no idea sudo was so bad!
It's coming to Linux now too. smh
Taking a step back: Is it really worth to jump through all these hoops just to avoid upgrading the source to python3? I am not a python person but what's the complexity of that upgrade? That discussion feels more forward oriented.
I actually agree with this but I didn't say anything because unfortunately my plate is rather full at the moment so I myself cannot contribute anything. Nevertheless, having something shoestringed yet usable is certainly welcome in the meantime!
I've done a couple python 2 to 3 upgrades (but not within Alfred). It's not too difficult but needs time and attention... neither of which I have at the moment.
It looks like before alfred-convert is updated to python 3, it'd make sense for the underlying alfred-workflow package to be updated to python 3, there's issue 182 and issue 97. Issue 97 is a older/longer discussion, in it user NorthIsUp links to their python3 fork of alfred-workflow which has commits as recent as a month ago.
Uh! Someone already did the work then?!
Sounds it lacking mostly a release package then? or am I misreading the situation?
I think misreading. There are two different packages – alfred-convert is built using alfred-workflow (both originally built by deanishe). It looks like work has been done to get alfred-workflow working with python3. It doesn't look like the author of the alfred-workflow-py3 has done any work on alfred-convert. If I had to guess, I'd guess that NorthIsUp did the python 3 work for a different Alfred workflow package that they use more often.
aaaah ... ok ... that would have been too good to be true :)
FWIW, homebrew does not do that (anymore). It uses
/opt/homebrew@tcurdt That's actually very good news!
Now, the million dollar question: can I install Homebrew alongside MacPorts? I would not mind having both installed at all.I just had a look myself. Evidently, /opt/homebrew is a Mac Silicon thing whereas /usr/local is still the default for Mac Intel (which is what I am on for the time being).
@hexadecagram, on Intel Mac, as far as I can tell, Homebrew does not change the ownership of /etc/usr/ anymore. It is root:wheel on my Intel Mac and I use Homebrew without any custom install folder.
It's working for me on v3.7.2 & v3.7.3, thank you very much @willemml! 👏👏👏
v3.7.2
-
Get pyenv path.
[ chusiang@macOS-12.4 ~ ] $ which pyenv /usr/local/bin/pyenv -
Go to workflows directory.
[ chusiang@macOS-12.4 ~ ] $ cd ~/ALFRED_PATH/workflows/user.workflow.XXX -
Replace the
YOURUSERNAMEby my username, likechusiang.[ chusiang@macOS-12.4 ~/ALFRED_PATH/workflows/user.workflow.XXX ] $ sed -ie "s/YOURUSERNAME/chusiang/" workflow/workflow.py -
Replace pyenv path on
info.plist.[ chusiang@macOS-12.4 ~/ALFRED_PATH/workflows/user.workflow.XXX ] $ sed -ie "s/\/opt\/homebrew\/bin\/pyenv/\/usr\/local\/bin\/pyenv/" info.plist
v3.7.3
By the way, the pyenv path problem has be fixed on v3.7.3.
https://github.com/willemml/alfred-convert/releases/tag/v3.7.3
Enjoy it.
@willemml , thanks for the fork.
In your new versions, the Python path is hardcoded. is it possible to use "Workflow Environment Variables" to let users define their own python2 binary path?
You're welcome @feigaoxyz!
It looks like there is already a fork that has been ported to python 3 instead of using the hacky method that I am using. I will not be updating my fork until it breaks (at which point I will probably try the python 3 fork which is mentioned in this comment by @giovannicoppola #91 (comment)) if you want to add variables for the paths feel free to fork my repo or even make a PR.
Facing the same issue I decided to write my own using Dart and compile it to a standalone native binary. The binary is signed and notarized by Apple.
Facing the same issue I decided to write my own using Dart and compile it to a standalone native binary. The binary is signed and notarized by Apple.
@techouse I think you've got the wrong link there but I did find your fork and it works great, thanks!
Facing the same issue I decided to write my own using Dart and compile it to a standalone native binary. The binary is signed and notarized by Apple.
@techouse I think you've got the wrong link there but I did find your fork and it works great, thanks!
@Noobish1 Ha 🙈, thanks for letting me know. The repo is techouse/alfred-convert.