Pain when installing a forked plugin

[Zankoku-Okuno]

I've made a fork of a plugin, and wanted to install it through package control now rather than wait for upstream (which is already in the default channel). I did eventually get it working, but only after some hours of attempted magic, most of which I have not bothered to report.

tl;dr:

• No ability to point at a single github repository holding a single package?
• Is the name of a release on github significant? I couldn't find any documentation to this effect
• Are pre-release versions ignored? Again, I could not find such documentation.
• This story can't be that uncommon (I'm the fifth fork of this same package), so I was surprised to only see it directly addressed in an issue, and then only sparingly.

I was at first misled by Add Repository, thinking it meant to add a git repository that holds a sublime package. I therefore used Add Repository typing https://github.com/Zankoku-Okuno/sublime-MoveByParagraph. This silently failed to find my package, even watching the console output. I'll admit the documentation /is/ clear, even if it doesn't call out this confusion explicitly. However, it got me thinking: why not allow this method, since it's far more streamlined than what I eventually ended up doing?

Following the advice of #258 (which perhaps should belong in the documentation), I created a github repo holding a package control repo—and if that's not an easy-to-communicate concept, I don't know what is /s. I didn't want to add a repository.json to my fork directly, as I didn't want it submitted back upstream. I made a 1.2.3-beta release in my fork and attempted to install. Package Control did find my git repo, but installed an unmodified version.

Finally, I made a new release, being very careful to mimic upstream's releases (you know, because cargo-cult works if you do it well enough). I'm not sure if the name of the release matters, or that beta releases aren't recognized. If the former, I couldn't find this in the documentation. If the latter, I couldn't find any documentation to the effect of ignoring pre-release versions.

[wbond]

You absolutely can “Add Repository” with a single https URL of a GitHub repo, or at least you could, unless something about the GitHub API changed. The only thing to note is that the repo name in the URL is used as the package name.

[wbond]

I’ll be at my desktop tomorrow and can provide more info and read/reply to any other issues.

[FichteFoll]

If the latter, I couldn't find any documentation to the effect of ignoring pre-release versions.

Package Control ignores pre-releases by default and only installs them if explictly enabled on a per-package basis. This is documented in the default settings file (and only there, afaik).

The name of the "release" does not matter, only the name of the tag does.

[wbond]

1. So the main docs (https://packagecontrol.io/docs/usage) do have an example of adding a GitHub URL as a repository. I just tested this and it works. The only thing to note is that it will use the repo name as the package name.

2. We don't have it specified anywhere in the docs, mostly because the feature didn't exist when Package Control was developed, but we don't use GitHub "releases" at all. Tags are used, and talked about at https://packagecontrol.io/docs/submitting_a_package. I guess the docs presume that if you are just forking a plugin you'll either have a working copy in your Packages folder, or will be running off of master.

3. There is a setting which controls prereleases, documented at https://packagecontrol.io/docs/settings.

4. I don't think it is that uncommon, but I think most people just clone into a folder in the Packages folder, in which case you don't have to think about any of this.

I was at first misled by Add Repository, thinking it meant to add a git repository that holds a sublime package.

I'm not sure why this didn't work for you. It just did for me. Could you provide the error you ran into?

Following the advice of #258 (which perhaps should belong in the documentation)

If you are interested at proposing some additions to the documentation, head over to https://github.com/wbond/packagecontrol.io.

[Zankoku-Okuno]

I'm not sure why this didn't work for you. Could you provide the error you ran into?

Unfortunately no. It didn't give me any unexpected output in the console. Having read the responses here, I now think that it didn't work because I was still using a prerelease tag without enabling prereleases.

I think most people just clone into a folder in the Packages folder

Yeah, that would be the easy workaround, but I have my Package Control settings sync'd across machines, and I wanted to leverage that to sync my forked package as well.

I think I've got my questions answered. I'll give it another go once I get home and close this if I don't have any problems. Thanks, everyone.

[Zankoku-Okuno]

Well, now a new error mode has appeared. I removed my custom channel and my package. Then I added my package repo and re-installed. The messages.json file was correctly interpreted and showed me the modified readme. However, the commands didn't work and I got the following error when it was reloaded:

reloading plugin sublime-MoveByParagraph.move_by_paragraph
Traceback (most recent call last):
  File "/opt/sublime_text/sublime_plugin.py", line 125, in reload_plugin
    m = importlib.import_module(modulename)
  File "./python3.3/importlib/__init__.py", line 90, in import_module
  File "<frozen importlib._bootstrap>", line 1584, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1565, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1529, in _find_and_load_unlocked
ImportError: No module named 'sublime-MoveByParagraph.move_by_paragraph'

My guess is that I could get around this by renaming the repo, but… well I don't want to. I'm thinking about contributing to a couple more packages, and it'd be nice to have all my sublime-related things prefixed with sublime-. Is there a more correct solution?

[FichteFoll]

My guess is that I could get around this by renaming the repo, but… well I don't want to. I'm thinking about contributing to a couple more packages, and it'd be nice to have all my sublime-related things prefixed with sublime-. Is there a more correct solution?

No, because packages with hyphens in their name can't be imported by Sublime Text's Python plugin runtime. You will have to work around this. Either you clone into the Packages fodler under a different name or you store your packages at a different location altogether and use symlinks from the Packages folder to reference them. Packages in general use the name provided in the name field when adding a package to the default channel, which is why their repository names can differ and have a sublime- prefix for repo organization. This is especially meaningful for packages providing key bindings or command palette entries for their settings files or themes with assets, because those require resource paths and depend on the package's name on the installed machine. As a result, you should generally develop packages under the same (folder) name but may choose arbitrary repository names.