Support passing needed config options via CLI, to avoid having to look at cap'n proto about vagrant-spk HOT 8 OPEN

If we want to do this, we'll also need to be able to express other platform features, like sharing roles, permissions, and so on.

We could theoretically add support for those in vagrant-spk or even just spk command, if we think this is high-value/significantly reduces packaging friction. If we take that approach, I think I'd want to make sure that we wrap all the platform features that are currently exposed via sandstorm-pkgdef.capnp, so we can have a consistent supported workflow.

from vagrant-spk.

from vagrant-spk.

@zarvox do I have your +1 to implement something that removes the need for editing the pkgdef, just for app name and the app action? I think less is more here; offering a convenience is good, and I don't think it means we need to wrap every feature of the platform.

from vagrant-spk.

I'm -0 on that, on the grounds that anything other than the example app is going to require editing it for version string, http bridge config, and so on. I don't believe you're actually saving any trouble for the vast majority of use cases, and I think it'd be instructional for developers to encounter sandstorm-pkgdef.capnp since it's the only way to do things like sharing roles, X-Sandstorm-Permissions, publishing, incrementing the app version, etc.

I guess given the above, I don't see what makes app name and action worth supporting without a plan for the others, and I suspect an ad-hoc approach isn't going to serve anyone well in the long run.

If you wrote it, I'd probably merge it, but I hesitate for it to become the officially-documented way to accomplish that task.

from vagrant-spk.

from vagrant-spk.

I guess the big difference between checkinstall and debian/rules is that with checkinstall you're not going to be redistributing the package, nor get it into the archive; you're just using the .deb as a transport and a way to fully uninstall a package. In Sandstorm, there's currently no separation of these concepts. And ultimately, if you want to redistribute the package, you're going to need to get your hands dirty with the pkgdef.

I also value simplicity and removing barriers where possible, and I also personally have found Debian packaging difficult to get into due to its complexity.

If we had a "test-only" or "local-install-only" short-circuited path, then perhaps that would be an approach that meets your requirements of "low cognitive overhead, easy to approach" and my requirement of "encourages high-quality package maintenance"?

from vagrant-spk.

And ultimately, if you want to redistribute the package, you're going to
need to get your hands dirty with the pkgdef

I demonstrated some situations earlier where I don't think this is true.
Could you respond to those specifically?

I also think we're somehow talking past each other here and I should
perhaps try this IRL.

from vagrant-spk.

If nothing else, for every update to this package, you're still going to need to at least increment appVersion and set appMarketingVersion to something sane.

I guess if your app is a write-once, throw-over-the-wall thing, then maybe you don't care about that either (nor permissions other than "all", nor API), and that's okay?

Maybe we want separate instructions for "one-off" packages and "no really I want things to work reliably long-term and not lose data on upgrade/etc."? There's a lot of lifecycle problems that go away if you're just hacking things and don't care about lifecycle/upgrades/etc, but I'm pretty sure eventually we want to have apps that can be upgraded and maintained. But they certainly make for a higher-overhead introduction.

Perhaps we separate these thoughts into "Level 0" "Level 1" "Level 2" packaging steps, and Level 0 is the "I just wanna run a thing once" and Level 1 is "I want this to do in-place upgrades cleanly" and Level 2 is "Level 1, plus I want to use specific Sandstorm platform features"? (Or pick your own definitions, but the idea is that the higher levels integrate more cleanly, are more maintainable, and are more fully-featured.)

from vagrant-spk.