limetext / lime

Open source API-compatible alternative to the text editor Sublime Text
http://limetext.github.io
BSD 2-Clause "Simplified" License
15.31k stars 1.07k forks source link

Restructure the project #546

Closed erbridge closed 9 years ago

erbridge commented 9 years ago

Related to #537.

I propose the following structure:

github.com/limetext/
    lime-backend/
        lib/ - currently backend/
        packages/ - submodule of lime-packages
        tasks/ - submodule of lime-tasks
    lime-qml/
        main/ - currently frontend/qml/
        packages/ - submodule of lime-packages
        tasks/ - submodule of lime-tasks
    lime-html/
        main/ - currently frontend/html/
        packages/ - submodule of lime-packages
        tasks/ - submodule of lime-tasks
    lime-termbox/
        main/ - currently frontend/termbox/
        packages/ - submodule of lime-packages
        tasks/ - submodule of lime-tasks
    lime-packages/ - currently packages/
    lime-tasks/ - currently tasks/
    lime/ - left as an archive

We should also try to preserve history using git subtree or git filter-branch for proper attribution and change history.

I'll do the work to make this happen, but is this a good structure to go with?

zoli commented 9 years ago
erbridge commented 9 years ago

We currently need the packages in the the backend for the tests.

I put the subfolders in so you can run go test github.com/limetext/lime-backend/lib/... without hitting errors due to there being other files in the root that aren't being tested (e.g. GoSublime). Try running go test github.com/limetext/lime/... to see what I mean.

zoli commented 9 years ago

I see, but there are just few tests relying on them and they should use testdata folder imo also this removes the go test github.com/limetext/lime-backend/lib/... problem for backend repo at least.

erbridge commented 9 years ago

You also get errors like this:

tasks/build/gen_loaders.go:24: main redeclared in this block
    previous declaration at tasks/build/fix.go:68
tasks/build/gen_python_api.go:394: main redeclared in this block
    previous declaration at tasks/build/gen_loaders.go:24

At least if we have a subdirectory, we're able to later include files that might be problematic in the root, without having to move everything around. There's also an neatness to having a relatively empty root directory, IMO.

erbridge commented 9 years ago

Having said that, I'm not strongly swayed against having it in the root if we can avoid import, build and testing issues.

erbridge commented 9 years ago

I had some time, so I did the work to split out the projects as I described above. I didn't bother preserving the commit history, since it would have been a lot of hard work for little gain (as long as this project remains around).

quarnster commented 9 years ago

History would be nice, but I'm ok with referencing the fork-point in the commit message as was done. History could be added in the future if anyone is feeling masochistic enough (IIRC I hacked it for the limetext/text repo via filter-branch and lots of trial'n'error), or if someone happens to be a git expert and knows of a simple and straight-forward way to do it.

erbridge commented 9 years ago

I started trying to filter out the history, but realised that it would be unreliable due to files moving around, and I couldn't work out how to follow moves sensibly. Google didn't reveal any nice way of doing it, either.

quarnster commented 9 years ago

FWIW I tried to get history working and re-pushed the lime-backend repo (twice...). Github still doesn't follow renames, but for example git log --follow lib/view.go does so atleast we have that now

erbridge commented 9 years ago

Nice.