I was wondering if there are good resources about migrating a typedesign-developer environment safely from python 2.7 to python 3.
I (finally) read the Notarisation Tutorial by @yanone (Thank you so much for compiling that) , but I am still generally scared by Catalina and that wicked extra effort.
Here’s what made me stand in my corner to shame:
If you’re still working with Python 2 they might not work (the subprocess part) and then I have to tell you that I don’t care and that there’s no help for you and that it’s 2019 and that you need to urgently go into a corner of shame and think about your life.
Well, here’s the thing:
I got literally thousands of .py files, and perhaps 90% of em are to be used in the type design workflow.
How’s it possible to migrate all of them to python 3? I cannot go through all of them and make the changes manually. Batch processing sounds rather scary, you never know what you break along with it.
What’s the safest way to get the actual Mac OS python properly set up to python 3. My Mac came with 2.7 and I often heard that it’s better to not mess with the the system python. But now I need to. How can one keep the dev environment working and migrate the system to python 3?
I am asking here, because this is rather specifically bound to GlyphsApp python integration, its API and an environment that was cast around GlyphsApp since years and years.
Thanks so much for any little twig of help.
On an unrelated side note:
I’m afraid that Apple causes the potential dead of many free plugins on the long run. With forcing to pay for a developer account and imprinting lots of extra work on the developers for each and every little plugin, the motivation to give work away for free gets minimised a lot. But that’s of course not your cup of tea
I am in the middle of compiling something about Py3 conversion. A good chance to clean out in your Py Database, that’s for sure.
Notarisation is not a problem as long as the plug-in is distributed through the Plug-in Manager. We have been discussing possibilities of distributing commercial plugins through the PM as well.
It is a semi-automatic process where you convert all your files using a command line tool called 2to3 that you already have on your computer, then debugging manually. It’s the only way known to me. You have to do it. But don’t worry, others have done it before you and survived
It’s not black magic.
This means going through each and every script and check if it still works? Meaning to set up the particular workflow situation each script is meant for?
Thank you anyway, I’ll have a look at that! @yanone So 2to3 seems to convert the python files, which is a good start.
But what I also need to know: what about the python on the system? Does one need to change the default python 2.7to py3 as well?
If so, how to do that please?
Also: will my python plugins still work on anyone’s machine, once I converted them to py3? Or do they also need to have the matching python?
In Glyphs I see that it doesn’t matter if I run print "a" or print ("a"). What’s happening behind the scenes? Is it importing the dependencies to make both pythons work?
Probably a good chance indeed. But I need to allocate some time for it.
Well, the PM is the problem. Good to hear that you’re thinking about possibilities for commercial plugins Hope they can integrate existing shop systems. It was already a long and hard way finding the suiting distribution system which is also not too expensive to keep the costs for end customers as low as possible.
Get Python 3 via Homebrew.
Then either change your code to be compatible with both 2 and 3, or be a man and just leave 2 behind you forever. Peace of mind. Force everyone else to upgrade, too. Once Glyphs 3 is out, Python 2 will be history for everyone in type design.
But generally, yes, you need to know which Python version your customers have installed, and ship your code accordingly.
When I install py 3, apparently both pythons are on the system. How to tell Glyphs or any other tool which py to use then?
Yes, I watched some videos and read documentations now and will definitely go for the hard way. No smooth transition.
Still afraid of the unicode and str issues, cuz I won’t be able to test the scripts that rely on those right away.
Glyphs 2 uses Python 2. Glyphs 3 will use your choice. In the command line you call python or python2 as well as python3. In your code you can define conditions using sys.version, but try to abstain from them at first.
The unicode situation is the single biggest reason to switch. Finally peace, with a small learning curve.
You mean, you have thousands of little tools? Or are your tools so complex that they require thousands of files (still, that sounds like something is wrong with the organization of the code)? Or are you counting obsolete versions of your Python files or duplicates as well?
All scripts that run inside Glyphs2 are python2 only. Internally it loads the system python. It is independent of the python version that you run from the command line (you still can mess up the environment if you botch the installation of a custom version).
I tried with a fresh install in Catalina. It supports python3 but only if you have the Xcode command line tools installed (similar as git works). So homebrew is still the best option.
Plugins (and scripts) can be made compatible with both versions. To be prepared, plugin developers will get an early access to a alpha version of Glyphs 3.
The installation of custom plugins outside of the plugin manager could be done with a custom URL handler. So you add a link on your website in the format (something like this) glyphsplugin://path.to/the_plugin.zip.
If you’d could see! I got a huge codebase of all kinds of tools, PDF and graphic generators and what not. Not only for being used for type design or inside of GlyphsApp. And I also keep lots of snippets as reference. I don’t think that you can judge if this amount is “wrong” or not. Also I just referred to a *.py count on my development folder.
From what I saw the convention is mostly about the print to print(). And dome methods in the plugins main class need an @objc.python_method annotation.
So it is a good idea to add the from __future__ import print_function in all scripts.
This is exactly why I’m so hesitant. It’s all more confusing.
And that: print (“hello”) print “hello”
both work in the Macro Panel without me having installed any p3 yet? I assume some plugin imports from __future__ import print_function at Glyphs launch then, right?
Hope they can integrate existing shop systems. It was already a long and hard way finding the suiting distribution system which is also not too expensive to keep the costs for end customers as low as possible.