01:50 <spyjoshx> I just started hosting a sandstorm instance for a small team of hobbyists and I was wondering if there is an easy way to make a grain out of an existing web app. I am already hosting a Rocket.Chat server and would like for my users to be able to use it from within sandstorm

02:14 <DanC> spyjoshx, Rocket.Chat is in the sandstorm app store already

02:15 <spyjoshx> I know, but I have an instance of it ALREADY hosted

02:16 <spyjoshx> (not in sandstorm)

02:20 <ocdtrekkie> spyjoshx: It'd be on the app to support that sort of thing. And Rocket.Chat's Sandstorm version is pretty old, shoehorning your database into it would probably break things.

02:20 <ocdtrekkie> Wekan supports import and export of boards which works between Sandstorm and non-Sandstorm versions, for example.

02:22 <spyjoshx> I'm talking about something like nextcloud does. Making a "pseudo-grain" that is basically just an iframe of my rocket.chat

02:36 <ocdtrekkie> My last experience with Nextcloud was when it was just ownCloud. :P

02:36 <spyjoshx> lol. But do you get what I mean?

02:37 <ocdtrekkie> I think there'd probably be concerns with embedding things outside of Sandstorm's security model inside Sandstorm, where people might be misled to believe they are being protected by Sandstorm's way of doing things.

02:37 <spyjoshx> hmmm.... Oh well. Thanks for your help! ;)

02:38 <ocdtrekkie> I personally wish it was a bit easier to move some of my LAMP stack "apps" into Sandstorm grains. I have quite a few floating around on a web hosting account which are mostly for my use only at this point, but I don't want to make them disappear.

02:39 <spyjoshx> Yeah! I know EXACTLY what you mean.

02:40 <spyjoshx> I found a really cool js gameboy emulator on github and am hosting it on my server as well. It would probably make a good grain for my group

02:48 <ocdtrekkie> spyjoshx: I have a little list of JS apps like that I'd love to package for Sandstorm, though there's complications. Most JS apps like that have an annoying habit of storing data in localStorage, which doesn't work with Sandstorm.

02:48 <ocdtrekkie> Sandstorm doesn't need an app to implement user management for a one-person app, but it does need the app to store data somewhere in /var on the server.

19:33 <TimMc> I'm still pretty confused about how app packaging is supposed to work in Sandstorm.

19:33 <TimMc> Am I correct in understanding that there's basically a process that watches you build and use the app, then collects all the files that it touches?

22:14 <ocdtr_web> TimMc: That's more or less the gist of it, though using alwaysInclude in the pkgdef file you can explicitly select things to include in the package as well.

22:34 <TimMc> I'll be honest, that gives me the willies. Seems too implicit.

22:45 <TimMc> I'd have concerns around reproducibility, debugability, and fragility.

23:28 <ocdtrekkie> TimMc: Rebuilding apps can definitely be fragile, if you've updated apps on a system and you're building with the spk tool. But it's very helpful when you have no idea what files outside of your project folder you need to run your application.

23:29 <ocdtrekkie> vagrant-spk is significantly more reproducible since the package runs and is assembled inside a VM, and your project's vagrant-spk folder effectively contains the scripts used to build said VM.

23:29 <TimMc> Well, I definitely wouldn't want to run it *outside* a VM. :-)

23:30 <ocdtrekkie> Note that since spk creates a list of files which are to be included in a package, it is relatively easy to see when included components change. Though that won't identify if versions of said files change on your system.

23:30 <ocdtrekkie> When I mess with packaging I use a Linux VM since I'm a Windows user, but I definitely prefer spk over vagrant-spk.

23:31 <ocdtrekkie> vagrant-spk has a lot of cool features, but unfortunately lives in unsupported land at the moment, since Kenton himself didn't develop it, and Asheesh and Drew aren't super active around these parts.