Is there a way to somehow select Glyphs python as the python interpreter in VSCode?
I get a lot of warnings from Pylance about missing classes/imports when using Glyphs builtin objects, which annoy me. Unfortunately Pylance does not offer any muting for certain items. I thought one solution could be to select the G Python as the interpreter (maybe that could also enforce autocompletion to a certain degree, but not needed much here).
When asking for the location of the Python, I just get the Glyphs binary, which I can’t use as the interpreter in VSC.
Or is there another trick to shut linters up on things like GlyphsApp, Glyphs, Font, AppKit, vanilla, etc?
Somehow related, I want to implement some unit testing that I could run outside of Glyphs. For this I’d also need to somehow access the Glyphs builtin modules and classes or at least mock them. Is there any way, to get an external IDE to “know” about those?
Or is there another way to execute the unit tests of a python plugin, maybe from inside of Glyphs then?
There is no way to get direct access to the interpreter that runs inside glyphs. The object model and API is only available while Glyphs is running. You would need to run the editor and the tools from within Glyphs.
There is the script that scan access Glyphs but that runs through a distributed objects tunnel. That doesn’t even allow to apply the wrapper so I doubt it will help you.
Maybe the tools you are using have an API/plugins that would awake it possible to write a plug-in for Glyphs that could communicate with you setup. But I don’t know anything about that.
In the mean time I managed to write a little wrapper to execute a unittest on a python plugin, which I can run from Glyphs. That’s probably even better, as I can use an open file instead of creating some mock objects.
So the Linting is something likely insolvable, the Unit Testing is solved. Thanks so much for your input. That helps a lot to better stop researching
I almost had that, but ".../GlyphsSDK/ObjectWrapper/GlyphsApp" instead of ".../GlyphsSDK/ObjectWrapper". No Idea where that came from.
Now I changed it to end with ObjectWrapper, and it partially works.
When I add from GlyphsApp import Glyphs or even from GlyphsApp import *, the Glyphs class is not complaining, but things like Font still are not recognized. Is that the same for you? I see it has access to everything that is stated in the __all__ of the object wrapper.
There is also some autocompletion working, but not much.
Yeah, it’s the same for me. Support is partial at best … there may be some things missing from the object wrapper, e.g. Font and Layer (they can not be imported in Glyphs either, but are “just there”). And the missing autocomplete and docs are probably due to the unusual way the wrapper is built, mostly referencing objc classes and methods?
Thanks Florian. Interesting find! Maybe that could help. I’ll have a look and let you know
This works like a charm
Steps to recreate, if anyone is interested:
Create a _GlyphsStubs.pyi file (any name you want) and put it in the top level scripts directory (or anywhere, where it makes sense to you).
Then in your VSCode settings.json add "python.analysis.stubPath": "[...]/_GlyphsStubs.pyi", (where the path points to that .pyi file)
In any python script add from _GlyphsStubs import *
Now depending on the content of the .pyi file, the linter accepts these objects like Glyphs or Font and the cool thing is, it offers autocompletion and even documentation (if there is any in the stub file).
Depending of how much my stub file might grow, it could be a nice addition to the object wrapper
Thanks for trying it! It’s probably best if there is one shared stub file instead of everyone having to redo the same work over and over again. Either released bundled together with Glyphs or published on GitHub.
The type stub system is more general; other software (like mypy, or PyCharm, I believe) can also read these .pyi files, in case someone is not using Visual Studio Code.
What do you mean you’re at this? Florian just proposed type stubs to have a look at, so I did Primarily I just want to get rid of false negative linting in my own, personal python environment, and it does not need to be complete for me. So I would just add the few classes/objects that VSCode complains about to solve that for me. I don’t think that it might be too useful for more than a handful other users, but would be happy to share a WIP file somewhere.
Hard to say. For example when I add constants to the stubs file like so, they are recognized. Those constants are also in the wrapper (and even properly declared there), but are not recognized.
Likewise, in the stubs there could be sth like that to be recognized:
def __init__(self): ...
The currently active Layer
def __init__(self): ...
def components(self) -> List[GSComponent]:
"""Proxy for Layer Components"""
So it’s basically more like a header file. The ellipsis are literally three dots and required, or if a docstring is added to a method, it needs a pass after that instead.
Glyphs is recognized from the wrapper, when adding from GlyphsApp import Glyphs or from GlyphsApp import *, but things like Font or Layer are not.
Not sure how I’d need to add type annotations to the wrapper in order to make it work.
The type hints can be added in the stub file methods (I just left them out in that example, because those are not needed, but it’s better when they are there. I updated the example with the components above).
Adding the type hints directly in the object wrapper: I don’t know if it could work. For me here it didn’t.
But what did you mean with “we are at this”?
Anyway, let’s not get too crazy with it. I think I got what I needed and am happy now