abstreet
abstreet copied to clipboard
a-b-street
Package Mac releases as .app
Would it be worth it to do the same with Windows releases? As in packaging as .exe?
Would it be worth it to do the same with Windows releases? As in packaging as .exe?
Maybe? I'm not sure what's the standard way to distribute things like this. The game internally needs to use a filesystem, and the actual individual files are useful for people to see -- like submitting data/player/edits.
I'm not a Windows or a Mac user and I don't have regular access to either. If anybody could help with this bug to simplify things for Mac folks, it'd be much appreciated!
I just opened https://github.com/a-b-street/abstreet/pull/896 to integrate macos code signing and notarization into the repository.
One question is how do we want to handle the many executables - does each become its own app? I think that makes the most sense for all the graphical apps like there'd be a OSMViewer.app an LTN.app a Game.app (probably better called ABStreet.app)
As for the command line apps like the cli and updater - I'm not sure. Maybe they should just be embedded into the main ABStreet.app?
Apart from that, some other things I think we'll have to do to get an app working:
- relocate the "data" directory into the conventional place within the app bundle
- separate read only "app data" (
Foo.app/Content/Resources?) from user writeable data (e.g.~/Library/abstreet) - Where would the updater download too? Does that directory get blown away between updates?
- integrate with system logging?
- icons!
I just opened https://github.com/a-b-street/abstreet/pull/896 to integrate macos code signing and notarization into the repository.
Awesome, thank you!!! I'll give this a spin this weekend, and with all luck, produce the first signed build tomorrow!
One question is how do we want to handle the many executables - does each become its own app? As for the command line apps like the cli and updater - I'm not sure. Maybe they should just be embedded into the main ABStreet.app?
Each executable as its own app sounds sensible to me, as long as they can share system and player data directories without any problems. I'd strongly prefer to not bundle the CLI and updater directly with the UI apps, because it'd noticeably bloat the compile time and final size. Size of all the executables total would increase noticeably by all repeating. (I don't have numbers handy, but I'm pretty certain I tried this out back when I started splitting things out and including the importer in the release.)
But maybe the updater and importer don't need to be apps at all, just signed and notarized? Nobody will double click them. The UI apps invoke them. I guess we can see what the rules are there.
relocate the "data" directory into the conventional place within the app bundle separate read only "app data" (Foo.app/Content/Resources ?) from user writeable data (e.g. ~/Library/abstreet)
We can already do both of these via https://github.com/a-b-street/abstreet/blob/b867859dde33975b11561f1abbdd6ec9ee8236fb/abstio/src/abst_paths.rs#L15. ABST_DATA_DIR and ABST_PLAYER_HOME_DIR are env variables respected during cargo build.
... Although looking at it, for the latter, it looks like it evaluates $HOME for the person running cargo build, which definitely isn't correct...
Where would the updater download too? Does that directory get blown away between updates?
To data/system, aka $ABST_DATA_DIR. I haven't actually tried out the scenario where data/system sticks around and all the executables are updated. Some files in data/system come with each week's build, like proposals. Maybe we need to further rearrange that first. And the UI may need to trigger the updater immediately after "detecting" that a new version of the code is running against a preserved data/system from a prior week.
Why do they need to share system and player Each executable as its own app sounds sensible to me, as long as they can share system and player data directories without any problems. I'd strongly prefer to not bundle the CLI and updater directly with the UI apps, because it'd noticeably bloat the compile time and final size. Size of all the executables total would increase noticeably by all repeating.
To clarify, I said embed it in the .app, not the executable — an .app (which is just a directory with a prescribed layout) can have multiple executables.
So something like:
> tree ABStreet.app:
/Applications/ABStreet.app
└── Contents
├── MacOS
├── game
├── updater
├── cli
So no individual executable's size should really be affected. One of the goals of this approach to software packaging is that, containing their dependencies, they are relocatable. Users can equally run ABStreet.app from their download directory or "install" it by dragging it to their system /Applications directory.
If each GUI app needed to use the update and cli executables, then this approach might mean copying the executables into multiple .apps. There probably a smarter way, but I don't know it off hand. But even if there's not, I'd expect the compressed download size to be only minimally affected from multiple copies of an identical executable. Whether it's a deal breaker if the on-disk installation size grows is a valid question.
edited: for consistency and to fix a billion typos, sheesh 🙃
then this approach might mean copying the executables into multiple .apps. There probably a smarter way, but I don't know it off hand. But even if there's not, I'd expect the compressed download size to be only minimally affected from multiple copies of an identical executable.
Ahh, thanks for clarifying. Repeating those two files for all the .apps doesn't seem that bad in a .zip. The bigger question is if all the apps can share the same data/{player,system} directories. Presumably that's possible, maybe with some permission approvals from the user's end. (I just accidentally blocked Terminal from accessing my Downloads folder... I like the stronger sandboxing in Mac, but the UX of sudden dialog boxes can be a bit jarring)
Just noting that I disabled notarization temporarily in 6bf2f6ba3259d4f7464c469c864210d73ecc99e1. The full error:
Error: HTTP status code: 403. A required agreement is missing or has expired. This request requires an in-effect agreement that has not been signed or has expired. Ensure your team has signed the necessary legal agreements and that they are not expired.
My apple account is tied to my UK phone number, which I currently don't have access to. I also don't currently have my Macbook on-hand. I can go through some alternate identity verification process that takes a few days, but I'll just wait till next week. 2FA fail!