Stop using glide

[zoli]

After a while using glide, IMHO its not useful at the current state of the project. Most of the repositories are under development, we aren't close to v1.0(or any stable state) in any frontends or backend and most of the changes are simultaneous in more than one repository(e.g backend and frontend, backend and commands).

[erbridge]

It is useful for managing external dependencies, though, keeping them pinned to known working versions. What problem are we facing, currently?

[thedodd]

What alternative should be used, and in what ways does it resolve a problem which glide is not?

[zoli]

What problem are we facing, currently?

It's causing Unnecessary glide update commits and travis failures. After a simple change in text repository or loaders we should change glide lock file in 4-5 other repositories.

What alternative should be used.

IMO we don't need any dependency management right now and we don't have much external dependencies already(for qml frontend we have only 2 external dependencies).

[erbridge]

The locks prevent the need to immediately update dependent code when making an API breaking change, though. Also, I had to pin fsnotify to an earlier commit when I last updated the locks, to prevent a panic, which would have been irritating to do without any tools, and I doubt it will be the only time an external update breaks stuff. That doesn't mean that glide is the only tool to consider, but I think keeping the ability to pin repositories is something we need for external dependencies, at least.

[ricochet1k]

Why is limetext/text, limetext/loaders, limetext/sublime and limetext/commands even in a separate repository? IMO they should all be in limetext/backend, which would mitigate the glide commits and other things and make it easier to update and rebuild the repos.

[zoli]

The locks prevent the need to immediately update dependent code when making an API breaking change.

The thing is while we are in active development and none of repositories are near stable we don't need this feature. We will definitely need glide or STH like that in future but for now I suggest removing it.

I had to pin fsnotify to an earlier commit when I last updated the locks.

I didn't know this but we can put fsnotify in a vendor directory in each repository that is using it.

Why is limetext/text, limetext/loaders, limetext/sublime and limetext/commands even in a separate repository?

There are some related discussions in https://github.com/limetext/backend/issues/94 but in short limetext/sublime and limetext/commands are optional for frontends(e.g we might have limetext/textmate for supporting textmate plugins later). About limetext/text and limetext/loaders they serve a specific purpose and aren't created just for backend.

[erbridge]

I see both sides of the argument... I still think using glide is better than submoduling vendor repos, but given that I'm rarely active here, I'll let you decide how to proceed.

[ricochet1k]

Is it possible to use glide selectively? So only use it for external repositories, not for limetext ones?

[erbridge]

I don't think there's a way to exclude packages, but I believe simply editing the lock file to have version: master instead of the specific commit would work.

[zoli]

Setting version: master or even not setting any version will work, but glide update will override both of them and will set a specific commit in lock file.

[erbridge]

True, but in practice the need to update dependencies happens rarely, and it's not hard to avoid committing the unwanted changes.

[zoli]

You're right, I'll change limetext repositories version to master in lock files.