search

sandstorm-io / vagrant-spk

Packaging tool for Sandstorm, a self-hosting platform for web apps!
Apache License 2.0
55 stars 29 forks source link

vagrant-spk pack should not rely on bidirectional filesystem sync working #85

Open paulproteus opened 9 years ago

paulproteus commented 9 years ago

See https://groups.google.com/forum/#!topic/sandstorm-dev/uHX7HO-FKzw for details.

zarvox commented 9 years ago

One (admittedly ugly) way to get the spk out of the guest if bidirectional sync is unavailable would be to FILE=$(mktemp) && vagrant ssh -c "cat /path/to/that/spk" > $FILE && mv $FILE output.spk (or the equivalent series with Pythonic API calls).

It'd be slower in the cases where bidirectional sync would work just fine, but it'd actually work in the cases where bidirectional sync is not okay.

Note that we'd need to do something similar for spk init, which also expects to be able to write through to the host for at least .sandstorm/sandstorm-pkgdef.capnp and /host-dot-sandstorm/sandstorm-keyring. If we want spk init to autogenerate shell projects with identicons or example changelogs to embed or .gitignore files or any other files, those would all need to also get written back to the host too. This might get out of hand.

paulproteus commented 9 years ago

+0 to abusing cat for this

Interesting point about 'spk init' though. Hmm.

zarvox commented 9 years ago

Here's a semi-crazy thought: if we don't mind duplicating code/comments, we could plausibly reimplement the spk init logic on the host in vagrant-spk instead of calling spk init in the guest.

Generating the app key is approximately trivial. How we generate the sandstorm-pkgdef.capnp is technically an implementation detail of vagrant-spk, so we could just as reasonably ship pkgdef templates in vagrant-spk and just render them to files on the host, skipping the roundtrip to the guest.

This would also give us a chance to add more stack-specific explanatory comments to the pkgdef, if appropriate.

And on second thought, at least the the .gitignore should probably get generated by the setupvm command anyway, since that's the one that makes all this .sandstorm stuff.

zarvox commented 9 years ago

Oh, more trouble: anything that involves caching on the host also requires bidirectional file sync. This includes global-setup.sh, which expects to be able to cache the current Sandstorm release package, and the meteor stack's setup.sh.

I'm not sure dropping the bidirectional sync requirement in general is viable.

paulproteus commented 8 years ago

I think you're right that bidirectional sync seems required, at least in the absence of pretty significant reworking.