So I don't know about things like gutter icons, but reading files from the package should now be possible from .sublime-package files as of build 3013 and the load_resource()/load_binary_resource() methods (http://www.sublimetext.com/docs/3/api_reference.html).

That said, I can see the benefit of being able to be able to keep a package extracted. The only downside of such an approach is that such packages won't be distributable in the .sublime-package format since ST3 will no longer extract the contents of it. That just means the user will have to use Package Control or something like git.

I am inclined to say that a flag like this will need to be in a custom packages json file, and won't be supported with the "lazy" github repo URL inclusion.

Yes, I am aware of the load_resource and that will allow me to fix one of my plugins easy enough. Allowing a package to specify it with a custom package json file might be a good compromise for the future.

I guess for now, I will have to fashion a system to know when to unpack selected files that can not be reasonably used with load_resource. Gutter icons cannot be used from an archive and must be in an actual folder relative to the default theme folder.

Also, the BracketHighligher plugin has its own plugin system to allow for modules that can tap into the bracket matching to allow for extended functionality, but the plugin must be able to dynamically import these files. I am not sure if that will easily work in an archive without unpacking the files (I know it doesn't currently work, not sure how much effort it would take to get them to work without unpacking).

I would definitely bring the theme issue up with Jon. It seems like an obvious defect for ST3 to default to .sublime-package files, but then not be able to load theme-related files.

But yeah, I think this is something that can be included in version 2.0 of the schema for package.json. Since we are going to be breaking backwards compatibility to add stuff like compatible ST versions, it makes sense to add other things also. Dependencies comes to mind too.

If you don't mind stopping over at #291 to add your two cents about this issue, that would be helpful.

I'm inclined to say there should be a special file in the repo, such as .no-sublime-package that will prevent PC from bundling it into a package file for ST3. This way people who install a package manually (not through the default channel) don't have issues either.

+1 for .no-sublime-package file

I think .no-sublime-package is a great idea.

I am also hoping Jon will eventually let gutter icon resources be used from package files making this a non-issue. Currently in order to get such resources to work, you have to unpack them, and to prevent issues, they need to be in a different plugin folder name than that of the archived plugin. It is very complicated, but I was able to get it to work. I have requested this change (use icons from the archive) from Jon, but we shall see if he is on board.

To get this working for BracketHighlgihter, which uses custom gutter icons, this is what I did. If the plugin is archived and the unpacked icon folder does not exist, I creaste the folder, and I use load_binary_resources to unpack the resources to a new plugin folder called Theme - BracketHighlighter. If the plugin is not archived, I still use load_binary_resources, and copy them over to Theme - BracketHighlighter. I also needed to know when to update the theme folder with new icons or new versions of icons, so I had to create some kind of version file that I unpack into the theme folder as well, and then at plugin load time, I compare the versions. If the versions are different, I delete the icons resources and version files, and unpack the new ones.

A different theme folder is critical so Sublime Text doesn't mistake the theme folder as the plugin folder. This is all unnecessarily complicated, but I was able to get it working for BracketHighlighter as a stop gap solution.

Yeah, it does seem there are some limitations right now with .sublime-package files, but in practice it should be a really elegant solution to allowing people to override things in packages. For instance if there is a Main.sublime-menu file in MyPackage.sublime-package, you can create Packages/MyPackage/Main.sublime-menu to override it.

You are right, I generally like the new system, and with load_resource and load_binary_resource, it is abstracted in a way that allows you to not have to think about whether you are in the archive or not.

It seems that if Jon resolves the theme issues, it should be possible for most, if not all plugins, to successfully run from an archive. I had had a big concern about BracketHighlighter being able to dynamically run its custom plugins from the archive, but Python is flexible enough that it was no big deal. You can use load_resource to read in the text, compile it on the spot, and then add it to the modules no problem.

            module = imp.new_module(module_name)
            sys.modules[module_name] = module
            exec(compile(sublime.load_resource(sublime_format_path(path_name)), module_name, 'exec'), sys.modules[module_name].__dict__)

Loading icon resources for the gutter is really the only insurmountable (unable to resolve without unpacking) issue I have come across.

Recent 3014 build allows for icons to be read from archives. Moving forward I think it is possible in most scenarios to get a plugin running fine from archives.

Since I cannot predict all scenarios though, it might still be nice to have this feature.

I've created a plugin ConvertToUTF8 (https://github.com/seanliang/ConvertToUTF8) for people to read & write files which contains CJK encodings.

But there are several dynamic modules (.so) files missing in the embedded Python on Linux (2 & 3) and OSX (3) which makes this plugin be not able to work fully.

So I created two extra plugins to solve this problem:
. Codecs26 for ST2 on Linux: https://github.com/seanliang/Codecs26
. Codecs33 for ST3 on OS X and Linux: https://github.com/seanliang/Codecs33

Codecs33 doesn't work as expected after installation via Package Control, although it does append the lib directory to sys.path.

I learned that Package Control now will "create a .sublime-package file and place it in the Installed packages folder", but "ZIP import of dynamic modules (.pyd, .so) is disallowed" (according to Python document: http://docs.python.org/3/library/zipimport.html). Then I extracted the Codecs33.sublime-package and move it to Packages folder, it works like a charm.

load_binary_resource() does not help.

Yeah, binary executables or libraries are problematic in a zip archive. I don't currently use any, but this is a good example of why an option to unpack would be great.

As of 2fb8c74 (on the python3 branch), .no-sublime-package files are now honored when found in a package.

Fantastic!