kentonv changed the topic of #sandstorm to: Welcome to #sandstorm: home of all things sandstorm.io. Say hi! | Have a question but no one is here? Try asking in the discussion group: https://groups.google.com/group/sandstorm-dev
<JacobWeisz[m]> I got it. I replaced whatever go build line was throwing me with make build since it has a Makefile.
<JacobWeisz[m]> And it works!
<JacobWeisz[m]> So I found someone basically making apps in a format that is inherently easy to package for Sandstorm (except for having to suffer Go tooling?) who also wants to have a shell to manage said micro apps...
<JacobWeisz[m]> I figured putting together a wee demo for "these would work great on Sandstorm" was worth attempting.
<JacobWeisz[m]> Okay, so, it works in in vagrant-spk dev, but not as an SPK. :/
<JacobWeisz[m]> It seems like all the stuff in the gopath stuff doesn't get seen by the spk tool.
<JacobWeisz[m]> I am hesitant to alwaysInclude it because I assume that could have all sorts of packages in it I might not want.
<abliss> it shouldn't need to be included. go binaries are statically linked by default.
<JacobWeisz[m]> I'll try and grab some grain log, but it looked like it was looking for stuff in home/vagrant/go
<JacobWeisz[m]> github.com/ocdtrekkie/todo is the package I am playing with.
<JacobWeisz[m]> It looks like the static css and images aren't detected by spk, but that's what it's panicking over not having.
<JacobWeisz[m]> Alright, we're good now.
<JacobWeisz[m]> It is pretty mobile friendly, like Yata. Arguably it has a better focus on style. But you can't uncheck items, so it's a little less functional than Yata, at least to me.
_whitelogger has joined #sandstorm
<JacobWeisz[m]> Ironically, high on HN right now: https://go.googlesource.com/proposal/+/master/design/draft-embed.md
<JacobWeisz[m]> go.rice sounds like the package that was upset about the static files being missing in the spk.
<isd> ocdtrekkie: I should have a look at the Go stack; they did a major rework of how their packaging system works in the past couple years and I can't remember if it's been updated since then.
<JacobWeisz[m]> FWIW, the listed package works. So it might just be some argument of 'go build' in build.sh that was problematic for me.
<JacobWeisz[m]> Replacing that line with make build ran the go build in the author's Makefile without an issue.
<JacobWeisz[m]> I might've also ran into issues with the pkgpath variable stuff in build.sh, but I ended up looking at sandstorm-filesystem I think, and mostly copying from there.
<JacobWeisz[m]> So yeah, it might need a look but it isn't too far off, I managed to hack my way to success without knowing much about Go.
<isd> I'll spend a minute tomorrow looking at it and maybe send a patch to update.
<isd> It does look like it predates modules.
<JacobWeisz[m]> I am going to maybe look at packaging more of the same author's "micro apps". Because they all work pretty much the same way, should be super simple now that one works.
<JacobWeisz[m]> Apart from being a slightly different color purple, the style is surprisingly similar to Sandstorm's. And they fit Sandstorm's granular model super well.
kawaiipunk has quit [Quit: Leaving this Club]
kawaiipunk has joined #sandstorm
frigginglorious has joined #sandstorm
frigginglorious1 has joined #sandstorm
frigginglorious has quit [Ping timeout: 256 seconds]
frigginglorious1 is now known as frigginglorious
xet7 has quit [Quit: Leaving]
<isd> It looks like the golang stack is pulling in Go 1.11, where the new modules stuff was still very experimental. The repo you're using is trying to use them, and from the looks of it if the golang stack understood modules it would have "just worked"
<isd> So we should update the toolchain and make sure the stack works with modules
<isd> It's kindof ironic that we're hitting bitrot in a stack for a language I use pretty often... but I don't really use vagrant-spk unless I'm packaging something that pulls in things like database servers.
<isd> My brain is chewing on ideas for a better approach. Did a git init nix-spk; stay tuned.
<JacobWeisz[m]> Yeah, I got the impression you were using docker-spk for stuff now?
<isd> No, just raw spk on my local machine for the most part
xet7 has joined #sandstorm
<JacobWeisz[m]> I would say I rarely feel like I'm fighting our tooling with vagrant-spk, but it definitely depends on good maintenance of the stacks.
<JacobWeisz[m]> In the ideal world, each stack would have a maintainer keeping it current with platform changes or something.
<isd> The other issue is that having a separate VM per app kills build caches; it means every time I start a new {haskell,go,ocaml,$other_languages} project, I have to re-build all of my transitive dependencies inside the VM.
<isd> whereas if I'm developing on my local machine there's a shared build cache and I don't have to re-build libraries used by other apps I've been hacking on.
<JacobWeisz[m]> I find it a feature, not a bug, that it does everything from scratch. Verifies the scripts you assemble actually will reliably build your package on someone else's machine too.
<isd> Eh. The build caches for haskell & go at least are reliable enough that that's really not an issue.
<JacobWeisz[m]> Probably at least twice every time I package something I end up doing a vm destroy and starting over.
<isd> Anyway building on top of nix is going to be a more robust strategy for reproducibility than "throw it in a vm," and will get most of the benefits of my current approach as well
<isd> I'd actually like to add a "nix-spk" stack to vagrant-spk once it's ready, so if you've got a nix-spk project and you're not already on a linux box with nix set up, you can just do vagrant-spk setupvm nix-spk and then the regular vagrant-spk dance will "just work"
<JacobWeisz[m]> That'd be nice.
<JacobWeisz[m]> I do occasionally try to package things on a Windows machine too. Sometimes it even works.
<isd> In theory, docker-spk should be able to build apps from a windows box without even having a sandstorm install anywhere (though you do need the capnp exe)
<isd> The only reason I haven't build binaries for windows is because I don't have a box to test on...
<isd> Go 1.15 will be out soonish, so I may wait until that lands to update the toolchain.
ill_logic has joined #sandstorm
<JacobWeisz[m]> If you had a "download these and run these commands", I'd happily test a docker-spk exe
<isd> You should be able to build it from source by following the instructions in the README. If you want to cross compile from a linux machine, just export GOOS=windows first.
<isd> You'll need docker and capnp in your path.
<JacobWeisz[m]> Random side note: David built the browserquest app on the Mozilla master that died in 2012, with his own hacks to copy localStorage to the server. The community version died in 2015, but has a server side database. I kinda wonder if it'd persist storage out of the box...