[RFC] Better distribution story for scry about scry HOT 16 CLOSED

I think that Scry distribution may be like ruby-ide as a shard or a system package via AUR (Archlinux) or a .deb (Ubuntu/Debian).

For now, I'm using the default nodejs backend for crystal-ide, some errors aren't detected by scry.
But Scry is a great project, is the way to get IDE support for crystal with VScode (format, symbols, suggestions, references) 👌

For debugging I'm using vscode-native-debugger. The crystal code is compiled with crystal build -d.

Bye! 🎄

from scry.

Scry would be less than 5 Mb 😄

crystal build --release --no-debug -s src/scry.cr

Edit: 😆

Edit2: 🤣

crystal build --release --no-debug -s src/scry.cr
strip -s scry -o scry.strip

from scry.

@keplersj I think you are right. I'm using Manjaro Linux, and I embedded Scry in my extension but is a bit hacky because it checks for extract Scry every time a crystal workspace is open.

Distributing the binaries would be a good way, so far I know, in ArchLinux we can use AUR and in Ubuntu a Launchpad repo, but I'm ok with a "releases" page on Github.

BTW:

I tried Scry on NeoVim and it works.

I think that completion goal, would be solved using cracker and embedding the crystal source with it inside Scry.

Some features like rename and symbols require some research to discover how implement them.

from scry.

@kofno If you're on board with the GitHub Releases strategy, could you set it up with your GitHub account when you get the chance? https://docs.travis-ci.com/user/deployment/releases/

from scry.

from scry.

I think brew would be the most logical way.

from scry.

@kofno now VSCode size extension limit is 100MB 😅

from scry.

I tried to ship scry.7z in my extension and it's only 1.5Mb

I think that with win32 and darwin binaries the size could be less that 10Mb

I'm using node-7z to extract scry:

function extractScry(path) {
	return new Promise((resolve, reject) => {
		let unzip = new SevenZip()

		unzip.extractFull(path + '.7z', path.slice(0, -4)).progress((files) => {
			console.log('Extracting Scry files...')
		}).then(() => {
			console.log('Scry Extracting done!')
			resolve()
		}).catch((err) => {
			console.error(err)
			reject()
		});
	})
}

See #L14

@keplersj did a great work with atom-scry. His code have clic-to-def 🙌

from scry.

@faustinoaq Thanks for the shout out! I'd love to unify the efforts - especially since I only have time to work on things like this as weekend projects.

from scry.

@keplersj You're welcome, I'm still learning how Language Server Protocol works 😅

from scry.

So here's my two-cents on this.

It sounds like the distribution strategy changes depending on the client and its needs. Sounds like VS Code wants the server binary to come packaged with the client package, however Atom prefers you to have the server binary downloaded on its own separate from the initial package download and install.

I think the best solution would be to have this repo build and publish versioned server binaries in archive files on the GitHub Releases page. Then clients can handle accordingly. VS Code packages could add a build step to download and incorporate into the final package, and Atom packages could access the archive directly.

@kofno and @faustinoaq: Let me know what y'all think of this strategy, I know how to implement this sort of thing using Travis.

from scry.

I'm open for whatever. Would love to get this going again. I hate work stuff change my focus, but I'm really glad people are interested. If we can get some PRs going, maybe that's the best way to start a discussion.

from scry.

@keplersj I like the idea. I will definitely set it up, but I'm hopping on a plane and I'm out of town for about 8 days. I don't think I'll be able to get that set up before I return.

from scry.

@kofno No worries!

from scry.

I'm going to try and look at this over the weekend

from scry.

@keplersj I've set up travis to do releases automatically. Were you going to take this the rest of the way, then? --> 95aa5a3

from scry.