vagrant-spk
vagrant-spk copied to clipboard
sandstorm-io
Support passing needed config options via CLI, to avoid having to look at cap'n proto
@phildini mentioned to me that he would drastically prefer if he never had to see any Cap'n Proto when packaging apps for Sandstorm.
To achieve this, we would need to at least allow the vagrant-spk user to provide the:
- appName, and
- appActionTitle
as parameters when creating the package initially, via vagrant-spk.
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.
FWIW, I think it's not super important to wrap all features, merely the stuff that all applications must use. I think it's OK to tell people that if they use more advanced features, they have to know what a capnp file is.
I bring this up because @phildini expressed a strong negative reaction to "having to learn another programming language" to write package files, and I sympathize, having been scared of "proper" Debian packaging for a while but having happily run "checkinstall" for ages.
@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.
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.
I want you to be as excited about this as I am, but I guess -0 means you'll merge it, so OK.
If possible, let's chat more IRL. I think cognitive burden is a cost; the question then is, what would make a developer interested in paying the cost? The answer is always some kind of positive benefit. Fishing through an obscure new "programming language" (this is what phildini called Cap'n Proto) is not fun if "all I'm trying to do is give my app a name."
For basic sharing, if you're OK with every sharing link giving full app access, which is the extreme case of "relying on the platform for access control", then you won't need need to edit the sandstorm-pkgdef.capnp.
When you start to use more interesting parts of the platform, I think you're in a mindset where you believe the platform has more value, and so you'll be more willing to edit a capnp file, or learn what capnp is.
Personally, emotionally, this sort of thing was a massive roadblock to me in Debian packaging, and I think massively limits the number of people doing Debian packaging.
In my case, I found "checkinstall" easy < https://www.debian-administration.org/article/147/Installing_packages_from_source_code_with_checkinstall>; I found debian/rules so hard that I didn't want to think about it for like 3 years, even though I was already building packages with checkinstall just fine.
Point is, I'll try to convince you of this, since I value consensus in addition to valuing getting my way. (Additionally, I could theoretically be wrong, so I guess I would like to learn that too if it's the case.)
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"?
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.
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.)