Package Control plugins using Git submodules

[Pyrdon]

Hi,

I have written a plugin that I want to make available using Package Control. Since a lot of the code is not specific to the plugin, but really general python or sublime-specific, I have made it use a Git submodule where this general code is defined. The question is then how I can ensure this submodule is also “installed” as part of this package. The code is hosted on Github, which does not support downloading zip archives including the submodules (right?). As far as I understand I have the following options:

1. Copy the source code instead of using a submodule. Obviously tedious and error-prone if I intend to create several plugins and having to synchronize code between them.

2. Use the support for dependencies within package control. If I understand this correctly this will however simply install a non-user-installable package under Packages/. How would this work with two different plugins, both being dependent on this package (and likely different versions of it)?

3. Have plugin-specific python code to somehow initialize all submodules using something like ‘git submodule update --init --recursive’. It needs to be run post install and on every update of the plugin, so I guess this can simply be run every time the plugin is loaded? A drawback of this is that it relies on Git, which is something not all users have installed.

4. Request the user to manually do what is mentioned in 3)

5. Either manually or through Github Actions archive the submodules and check them in to the plugin repository (or any other https-supporting webservice).

Am I missing something here? Seems like this is an issue that someone else should have already encountered?

[deathaxe]

Use the support for dependencies within package control. If I understand this correctly this will however simply install a non-user-installable package under Packages

Package Control 4+ converts legacy dependencies to python packages (wheels) and installs them to Lib/python3x folder for backward compatibility purposes.

Majority of dependencies libraries (which are just python packages) are deployed directly via pypi these days. PC downloads platform specific wheels and installs them to Lib/ folder.

You could use Github Actions to build a wheel from your library code and register it at github.com/packagecontrol/channel. An example to start with might be https://github.com/packagecontrol/sublime_aio.

plugin-specific python code to somehow initialize all submodules using something like ‘git submodule update --init --recursive’.

Plugins shouldn’t expect git to be present and thus shouldn’t rely on it for bootstrapping.

Either manually or through Github Actions archive the submodules and check them in to the plugin repository (or any other https-supporting webservice).

Emmet uses Github Actions to build release artefacts, which ship code from submodules.

Package Control 4 can theoretically download custom github release assets, but this requires some upstream changes to packagecontrol.io to support repository scheme version 4.0.0 to get widely available.

Alternatively provide a custom repository.json pointing to such custom download assets in e.g. master branch.

[Pyrdon]

Use the support for dependencies within package control. If I understand this correctly this will however simply install a non-user-installable package under Packages

Package Control 4+ converts legacy dependencies to python packages (wheels) and installs them to Lib/python3x folder for backward compatibility purposes.

Majority of dependencies libraries (which are just python packages) are deployed directly via pypi these days. PC downloads platform specific wheels and installs them to Lib/ folder.

You could use Github Actions to build a wheel from your library code and register it at github.com/packagecontrol/channel. An example to start with might be https://github.com/packagecontrol/sublime_aio.

Maybe I misunderstand it, but it is not an encapsulated library that I am using. It is just some custom python code for interaction with the Sublime Text API, but general enough to not really be part of this plugin. I guess dependencies/libraries are not what I am supposed to use then? I looked at sublime_aio and I understand that this builds wheels of that package, but how would I then incorporate that in the actual plugin?

plugin-specific python code to somehow initialize all submodules using something like ‘git submodule update --init --recursive’.

Plugins shouldn’t expect git to be present and thus shouldn’t rely on it for bootstrapping.

Agreed

Either manually or through Github Actions archive the submodules and check them in to the plugin repository (or any other https-supporting webservice).

Emmet uses Github Actions to build release artefacts, which ship code from submodules.

Alternatively provide a custom repository.json pointing to such custom download assets in e.g. master branch.

I don’t see any use of submodules in that plugin, but I do see that it builds and deploys it to the download branch. I however don’t understand how I incorporate use of that built package.

[deathaxe]

It sounds like the most reliable way for you is to just copy common code into your package and avoid all sophisticated attempts to outsource it.