Could it be that this causes also incompatibility problems, when one plugin requires module foo v3–4 while another requires v1–2? Might be a rather non-real scenario, but I wonder.
We need to think about this.
The current plan is to not use info from the repo but to put it into the packages file. That way we have at least some control over the versions and such. And plugin developers need to be aware that they can’t rely on specific version and fail gracefully with different (probably newer) versions.
And those extra modules should be used sparsely to avoid filling up the site-packages folder for users.
1 Like
I’ve tried to remove a dependency that was bundled with my Unicode Info plugin.
The dependency is jkUnicode. The problem was that it was bundled with multiple of my plugins, some public, some private. Now, the version needed for Unicode Info has gotten some substantial changes, so that all the older versions are suddenly incompatible.
When it is bundled with plugins (inside the Resources folder), I have no control over which plugin is loaded first and “wins” the import of jkUnicode. So even though the current version is bundled with the plugin that needs it, I have to uninstall 3 other plugins that get loaded before Unicode Info, before the import actually uses the current version.
I’ve tried two ways of solving this:
-
Add an entry for jkUnicode as a dependency in the plugin manager. This seems to work, but only for new installs of Unicode Info. Updated installs don’t “notice” the new dependency, so they stop working, and need to be manually uninstalled (manually because the plugin manager apparently doesn’t list plugins that crashed as installed?), then installed again through the plugin manager.
-
Add the logic mentioned above: Try importing jkUnicode, and if it fails, use the code to run pip inside Glyphs to install jkUnicode in the
Scripts/site-packagesfolder. This works, but it is very verbose (currently, all the code has to be added to each plugin that needs it); it gives me no way to check if I should install the package again in case it gets updated on PyPI other than to install it again on every launch; and it gives me another install of FontTools inScripts/site-packageseven though FontTools is still available from elsewhere (in my case the~/Library/Python/3.10/...folder). This instance of the FontTools package also will never get updated.
It would be very desirable to get a better way to install and update dependencies.
@jkutilek IMO any plugins that import jkUnicode should expect to get a recent version. If you have a plugin that needs an older version of jkUnicode, you’re right to bundle it in the Resources folder, but you should also rename it to something like Resources/PluginName_jkUnicode to prevent conflicts, and then replace all import statements with the new module name.