github package with a git submodule dependency?

[quarnster]

I recently broke some common code from an experimental branch of SublimeClang and the master branch of SublimeJava into its own repository, and added that repository as a submodule to these two projects. However, when installing SublimeJava using package control it does not also install the common git submodule. Is this some configuration setting I have not done or is it not supported yet?

It seem the zipball doesn't contain the submodule data, but it does have a ".gitmodules" which could be used. That file does not specify which revision to use of the submodule though...

[kizu]

@wbond +1 to the question “Do Sublime Package Control support submodules?” I'm in a process of creating a plugin for Sublime and I want to have some submodule dependancies in it, so it would be a bummer if in that case I couldn't use package control.

[wbond]

Package control simply downloads zip files from GitHub. If GitHub doesn't provide submodules in the zip (which appears to be the case) then it is currently unsupported.

[kizu]

So sad.

Is there a way to do at least as @quarnster said — look at the .gitmodules and download the dependancies as zips in the same way? Yes, the exact revision of submodule wouldn't be used, but there'd be at least a way to use submodules.

[quarnster]

It's possible to get the exact revision via the github api. In my case https://api.github.com/repos/quarnster/SublimeJava/git/trees/master. If I get some time over I'll dig through the sources and see if I can come up with a pull request for this.

[quarnster]

FYI got started on this. Halfway there by trying to get the right urls and commits of github submodules. Second part would be actually downloading them too, but now I'm off to a run :)

[wbond]

I appreciate the work on the git submodules @quarnster, but I would kind of like to take a step back and think about the bigger picture.

While lots of packages use Git, there are a fair number that don't. I think it would be preferable to come up with solution that allows for package dependencies using some JSON in the packages.json file. After that is determined, then we can see if git submodules can solve this for github repos.

The idea of package dependencies then also leads down the path of version conflicts. Unfortunately Sublime can only have a single copy of any given python module loaded at any given moment. We should probably discuss how to handle version conflicts in dependencies.

[du-song]

+1 from a SublimeJava & SublimeClang user

[kizu]

@wbond well, the submodules can be used not only for package dependencies — for example, I want to move the core of a plugin to a submodule that would be attached to different repos for different editors, so it won't be something exrernal, just a cross-editor lib. And the submodule is great match for it. But right now I'd need to create a different branch/repo only to provide a version with expanded submodules for package control.

[wbond]

@kizu Right now Package Control is really a JSON client that has special handlers for the GitHub and BitBucket APIs, which are versioned. Adding code to handle git submodules now takes it into the territory of also being tied to Git internals and having to keep pace with any changes there. I'd really prefer to reduce the number of external dependencies, not increase them.

I understand that git submodules make it easier for development, but Package Control isn't really trying to solve any development problems, but deployment problems. Right now you can already use git submodules all you want, you just need to package your .sublime-package files yourself. This means running the "Create Package File" command from Sublime and uploading the file to any web-accessible server.

[quarnster]

@wbond, I didn't know about the ability to package as .sublime-package. That IMO lowers the priority of this issue considerably.

To get this to work the package_control_channel repositories.json would have to be updated to point at the .sublime-package too right? Or does it point to a json which in turn points to the .sublime-package? Is there an example I can look at that is using this method of package distribution? :)

[wbond]

@quarnster The repositories.json needs to point to a JSON file that lists packages. For example, http://sublime.wbond.net/repositories.json (Source: https://github.com/wbond/package_control_channel/blob/master/repositories.json) includes http://sublime.wbond.net/packages.json.

In my packages.json I manually maintain all of the metadata, versions and URLs. When I want to release a new version, I upload the .sublime-package file to my server and then increase the version number in packages.json and upload it.

Inside of Package Control, there is code that manipulates the JSON from the GitHub and BitBucket APIs to get it to look like the JSON that Package Control uses.

[FichteFoll]

I think this is the right way to do it. The current implementation looks for zip archives in the download url (.sublime-packages are .zips), unpacks them and moves them into the Packages dir.
The same thing could probably be achieved with dependencies (like specifying another url which points to a zip file).

But I'm not too sure how to handle cases where multiple packages have at least one dependency that is equal. Save them to a special location or save copies in their folders? And about multiple versions?

[wbond]

I'd like to move the conversation about dependencies to #166. As I mentioned earlier, for now I'd prefer to talk about a general case solution for dependency management. Once we have some talk about that, then we can discuss if special-casing git submodules is reasonable.

[quarnster]

As the original requester I'm fine with closing this issue. Zipping all the submodules up into a sublime-package works fine for me.

[alecthomas]

I realise this has been closed for a while, but for anyone looking for a fairly convenient alternative I can highly recommend git subtree. Unlike submodules, subtrees are committed into the containing repository.

[smac89]

I was able to find a workaround for this, by creating a tag which points to a ref containing the contents of the submodule. See https://github.com/smac89/autodark-sublime-plugin. The workaround is embodied in the release.sh script found in that repository.