ModuleNotFoundError: No module named 'tamil'

[Dash (Aadarsh Rajan)]

Hi there,

I have a script that exports a test case based on my designed glyphs.
Everything was working perfectly fine for a year until today when I ran the script and got an error saying
ModuleNotFoundError: No module named ‘tamil’
Here’s the beginning of the code

Here’s a screenshot with the sys.path printed

When I do pip list on terminal I do see that the module ‘tamil’ is indeed installed

I have zero idea about what could be happening. For some reason the module isn’t being detected by glyphs? But this hasn’t been the case until today.

I’m running 3.2.3 (3260) and python version 3.11.9 (Glyphs)

Really appreciate the help, thanks!

[kalapi (Kalapi Gajjar-Bordawekar)]

Hi Aadarsh,

All your sys.paths are referencing folders inside Application Support/Glyphs 3 and the tamil module is either in you default usr/bin or a virtual environment’s usr/bin.

I’m guessing that this is the script you’re referencing? If so, copy the parent tamil directory into the root of the Scripts folder (i.e. inside the Scripts folder; accessible via Script>Open Scripts Folder).

Works for me this way. I’m on the same version & build as you.

[Dash (Aadarsh Rajan)]

Hey Kalapi,

Ah, I see. Silly me I thought that glyphs would detect a module installed globally. So I reckon this should be done for every module used within a script as well?

In case modules are installed globally, do you recommend I switch to the python version (python.org)?

[GeorgSeifert]

You can either use the Glyphs python and install the modules into it (as described above) or directly switch to the global python in Preferences > Addons. Then it will use the modules installed there.

[kalapi (Kalapi Gajjar-Bordawekar)]

My approach to managing modules (outside the Glyphs environment) is to install them in a sandbox/virtual environment (as is usually advised to keep the default installation as clean as possible).

From Princeton Uni CS dept:

In a nutshell, Python virtual environments help decouple and isolate Python installs and associated pip packages This allows end-users to install and manage their own set of packages that are independent of those provided by the system or used by other projects.

For me this is beneficial because I have different versions of fontmake, fontbakery, fontTools etc. in different virtual envs. to cater to the requirements of specific (sometimes ‘legacy’) projects.

My recommendation would be to add all the modules you foresee using inside Glyphs directly there using the method I described above (because it set-it-and-forget-it, at least until you upgrade/system update your computer ofcourse!)

I’m okay with having multiple ‘installations’ of modules in different sandboxes as long as I have a track of where they are.

[Dash (Aadarsh Rajan)]

Ah, thanks a ton Georg and Kalapi!

Understood. Shall try to maintain the same etiquette of installing the python and relevant modules in virtual environments going forward.