New approach for lime package management

[zoli]

This is a suggestion for lime package managing.
For now we have these package types:

• Settings
• Keybindings
• Syntaxes
• Plugins
• Themes

Each of them will be a type implementing Package interface, The init function will be responsible for scanning paths, finding packages and keeping the hierarchical priority
For each Package type the Get() method will be responsible for returning useful data that we will need for adding that package for example for a Plugin it might be returning python files or for a Setting returning the the data in the settings file, The important point is we won't load the package we just will prepare it for loading the package it would be something like this:
Settings

for _, setting range packages["settings"] {
        loaders.LoadJSON(setting.Get(), e.Settings())
}

Or Plugins

for _, plugin range packages["plugins"] {
        for _, f range plugin.Get(){
                 s, err := py.NewUnicode(plugin.Path() + "." + f.Name()[:len(f.Name())-3])
                 m.Base().CallMethodObjArgs("reload_plugin", s)
        }
}

If this approach is fine i will continue committing to this branch until it's done.

[quarnster]

It's not clear to me what the intent behind the interface and its methods are, please add a brief comment in the code on what each function is meant to accomplish

[zoli]

It's more clear now with using the new approach for loading plugins.
BTW still there is work to do it's not clean and some more functionality for reloading packages will be needed, I just wanted to show what I'm tending to do.

[quarnster]

Nothing references this method. Is it really needed?

[zoli]

Not sure really i thought it might be needed on reloading or something else.

[quarnster]

Btw, I don't mean to be difficult, just for the backend package I'd like to keep it as slim as possible and as well designed as possible, especially when introducing new interfaces. Ideally only methods and API's that must be exported (i.e. used by a frontend or to enable plugin-flexibility) and in this package should be, the rest should be unexported or even better in another package. (Opened up #282 to deal with cleaning up existing code there.)

I'm asking the questions because I don't know the answers myself, and I'm hoping that you or someone else watching this project might get some ideas from them. So please see my questions as trying to guide the thinking around the api and what it should accomplish rather than as a stick to punish you with :)

[quarnster]

Also, if you'd like more time to work on this, feel free to close the pull request and open up a new one when you are ready for a review.

[quarnster]

(btw2: please raise questions like this for existing code where it doesn't make sense as you stumble upon it, I'm sure there are many "wtf?!" code bits in there)

[quarnster]

Another point to consider is that ST3 can store packages in a zip file named "*.sublime-package", so the .py, .sublime-settings etc would all be contained inside of that zip file.

[zoli]

When i started reading limetext code about 2 months ago i was thrilled by the design of backend truly it's elegant and clean so i was worried that i might damage the design, I maid pull request before completing the feature for getting some feedback to be sure i'm in right path.
Being somehow difficult is really necessary for keeping the design slim, I will keep this request open for pushing more commits to resolve the concerns, implementing the reload functionality and dealing with zip packages.
Btw, I have more free time these days and will try to make more contribution to move this project forward.

[zoli]

Except reading Packages from zip files, I think we're done here. Reloading and scanning plugins, settings, commands and etc are enabled even the backend has not much problem with loading plugins with different languages than python we can scan plugins with special suffix.
Any idea why travis is failing all tests are ok in my system?

[quarnster]

sublime_test.go:27: 00002960 162 [2014/05/27 10:34:37 UTC] WARN open ../../3rdparty/bundles//VintageousCHANGES.txt: no such file or directory

Looks like a '/' is misplaced? Are you running the tests via ./tasks/ci/lime.sh in $GOPATH/src/github.com/limetext/lime?

[zoli]

I was using go test ./backend/... but with ./tasks/ci/lime.sh works fine to I am receiving SUCCEEDED for both backend and frontend/termbox

[quarnster]

Who makes use of this function? What does the "suffix" parameter do? Please add comment in code

[quarnster]

Again, I hope my questions and comments aren't too demotivating. Many them are rhetorical in nature and not to imply that what you've written isn't good. My hope is to awake discussion, insight and a well defined api with clear documentation (and again, same goes for existing code already written, please question it where it doesn't make sense and add documentation where needed).

But let me be clear: I do not require you to make all changes suggested here before merging. We can merge now, open up a separate issue number to deal with remaining items and you can work on something else if this is becoming tedious :)

IMO it's better to move forward and make incremental improvements than to have everything be perfect on first try. Some of these things we've discussed here isn't 100% important for a 0.1 release for example, but they are good to start discuss so that we have a better idea of the problems involved and the possible solutions once we reach 1.0.

[zoli]

Not at all,I really like to help this project move forward and my motivations are the same as mentioned in limetext readme

People including myself were wondering if the product was dead and I personally wondered what would happen to all the bugs, crashes and annoyances that still existed in ST2.

Also I am learning here that how should i think on designing a program and what questions should i ask myself before creating different components.
Sorry if i am taking your time too much.

I will fix some parts that might cause errors for merging and will create separate issues for other problems.

[quarnster]

No need to apologize, your help is very much appreciated and like I said, we don't need to be perfect on first try and certainly not for 0.1.

This stuff is good to discuss and think about so that once we reach 1.0 we are happy with how all parts fit together. By exchanging ideas and discussing different needs we'll get a better plan for all the different parts, even if we don't end up solving all of them or will need to throw out code and re-write if we find out that the current design is insufficient or has problems that we didn't think of back then.

Same goes for all existing code. If it doesn't make sense, is too complex, could be moved to another package, etc it should be discussed so that we can either figure out why it looks like it does (and add in comments about it in the code and/or wiki) or come up with an improved solution.

In that spirit, please don't see this as taking up my time or any one else's. Discussing the details and trying to figure things out are very much part of the process and are absolutely necessary in arriving at a satisfying solution. Personally I'd be more worried if there wasn't any discussion as that would mean we aren't thinking enough about the code or that we are too similar and aren't able to think of potential problems that perhaps others could :)

[quarnster]

Thanks for opening up separate issue numbers for the various things we've discussed here. Are you still working on any bits here or looking for feedback? If not, lets merge and we can deal with the remaining bits in these other issue numbers.

[zoli]

I'm working on some easy fix problems that will be finished by tomorrow after that we can merge this.

[zoli]

I think we're done here. This could be merged

[quarnster]

Cheers, let's continue discussion in one of the newly filed issues or open up a new one if one is missing.