3rd party software distribution

[Philip Monk]

Attached is an initial writeup of how 3rd party software distribution can work.  The part that's hardest to determine by argument is whether "blending" will actually be convenient or if it'll commonly result in delayed updates or other issues.  The way to be convinced about this is to use it over time, and fortunately we can start trying immediately by running `|sync %home ~middev %kids` to install the %srrs app and keep it updated (I recommend only doing this on a moon for now).  This is an experiment, we'll see how it turns out.  Will it blend?

If you have other apps you're interested in serving consider putting them on a ship in a public desk and telling us about them.  I'm going to keep moons with lots of apps installed for a while.

Also, for those unaware, the highest signal place to talk specifically with developers of 3rd party apps is probably ~littel-wolfur/----the-forge, where I've been discussing this a bit.

[Philip Monk]

To follow up on this thread from a few months ago, the biggest issue here is that you can't unmerge what you've merged.  This means you can't uninstall anything, and you can't switch from an unstable version of an app back to the stable version even if there were no state changes.  You've lost the info that any particular file is associated with an upstream desk, so you don't know how to remove it.

A possible solution is to mark each file with an upstream source desk.  Then, "uninstalling" is removing each of those files.

I suspect a better solution is to make %home be a "view" of several desks.  In other words, it's a continual merge of several source desks, such as sponsor/%kids, our/%local, ~middev/%srrs, etc.  If there's a conflict it rejects the update, and you could specify the merge strategy; for example, you probably don't want 3rd party code touching files they didn't introduce.

To uninstall, you simply remove one of the source desks.  It's conceivable this could fail by introducing a conflict between the remaining desks, but it's unlikely.  If it did, it would generally be because one of the remaining desks depended on the the desk you removed, even if that dependency wasn't explicit.  In that case, removing the one without the other must either fail or break the invariant that "everything works".

If this is indeed the answer, then there are only two infrastructural tasks required for "safe", generic software distribution:

- Implement "view" desks as described above

- Implement a way to remove apps and/or make them dormant (i.e. resolved to vases of their state, so they can be resuscitated in future if desired), as described in the original distribution.txt.

"Safe" means the act of installing software won't wreck your ship.  However, you're running 3rd party code, and *that* can wreck your ship any number of ways.  But if you trust the author, you're probably fine.  This is far better than our current situation, where no matter how much you trust that the author has your best interests at heart, you shouldn't install 3rd party software if you care about reliability.

UX-wise, we need utilities to:

- See and modify what desks are "installed" and with what configuration (merge order, merge strategies, associatd apps/files, etc)

- See which source desks are up to date with your base distribution.  For example, it's useful to see that a 3rd party desk is not up-to-date yet with the new base OTA.

- Suspend a source desk until it gets up-to-date.  This should put all its apps to sleep and automatically turn them back on when they get the base OTA.

[Matilde Park]

> I suspect a better solution is to make %home be a "view" of several desks. In other words, it's a continual merge of several source desks, such as sponsor/%kids, our/%local, ~middev/%srrs, etc. If there's a conflict it rejects the update, and you could specify the merge strategy; for example, you probably don't want 3rd party code touching files they didn't introduce.

This brings to mind some latent discussions on splitting out Landscape as a downstream distribution — depending on when we enact this "view", it might be a good time to enact that simultaneously as well…

—
~haddef-sigwen
https://urbit.org

[Anton Dyudin]

Mirroring from chat one thought on all of this: with ren/ gone, there's really no reason for ford-fusion not to just compile every single .hoon file in the desk. /=home= could then be free not only of textual conflicts, but also type errors, and  constitute the always-green most recent(/ and each recorded previous) building merge.

Perhaps with some primacy given to system files, such that if a core-distribution update triggers a failing merge, it is also retired against the *current /=home= contents* (in case the failure is coming from some other upstream); a core OTA incompatible with what's already running ofc cannot be merged.

With ^~ this could include deterministic compile-time tests, though I forget if the semantics there are "on input-independent crash abort the compile" or "on input-independent crash emits [0 0]". Theoretically even running .^ inside a const expression is perfectly safe, though probably just use ford directly for that - it's not like you can get your hands on a real % otherwise. 

--
To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@urbit.org.