Renames

[joshaber]

Sometimes, apps change their names. Sometimes. Squirrel should support that. We only change the name if:

1. The user hasn't renamed the existing app.
2. There's no app already named the new name.

Also, it should be noted that I have no idea what I'm doing.

[mdiep]

Maybe call this renamed target to make it sound less like it's renaming the target on disk?

Also, this method could really use documentation.

[keithduncan]

I think I’d like to call this useUpdateBundleName so that it’s clearer what the final name will be, rename here could imply using or not using rename(2).

Alternatively, we could be even more descriptive and make it a targetPathComponent: NSString? parameter. This would indicate the lastPathComponent on top of the targetBundleURL.stringByRemovingLastPathComponent that we’re requesting the update service to put the update into.

[joshaber]

Alright @keithduncan, see how that strikes you.

We still have the launchd problem, but I wanted to make sure this addressed your other concern first.

[keithduncan]

Can we use sourceURL.lastPathComponent here?

[joshaber]

I think the bundle's executable name is more canonical than what the zipped thing is.

[keithduncan]

@mdiep could you tie break on this one

[mdiep]

I don't know why these would ever be different at this point. It seems a little weird to me that this is even a key in the Info.plist. But given that it's there, I agree that it seems more canonical than the URL.

[keithduncan]

I’d like to get another 👍 from @jspahrsummers (if still interested in maintaining Squirrel.Mac).

What do you think we should do about the launchd concern?

[joshaber]

What do you think we should do about the launchd concern?

Yeah so this is interesting. It seems like Squirrel has always had this problem.

Before:

1. Start the update.
2. "Acquire" the bundle to update, which really means move it.
3. 💥 ShipIt is no longer where we registered it.

Now:

1. Start the update.
2. Rename the thing if needed, or "acquire" the bundle.
3. 💥 ShipIt is no longer where we registered it.

Both before and now, after the first step in the update process there's no going back.

We could try re-registering the job with the new path, but it's not clear to me if we can since it'd be a different bundle than the original one.

But at any rate, it seems like a pre-existing condition so I'd prefer to get this merged and address it later.

[keithduncan]

Yeah so this is interesting. It seems like Squirrel has always had this problem.

Weird, you’re totally right 😖

I’ll wait to see what @mdiep says about which name to prefer then we can

[keithduncan]

[joshaber]

[jspahrsummers]

IIRC launchd copies the ShipIt executable when the job is submitted.

[keithduncan]

$ launchctl list com.github.GitHub.ShipIt
{
    "StandardOutPath" = "/Users/keith/Library/Application Support/com.github.GitHub.ShipIt/ShipIt_stdout.log";
    "LimitLoadToSessionType" = "Aqua";
    "StandardErrorPath" = "/Users/keith/Library/Application Support/com.github.GitHub.ShipIt/ShipIt_stderr.log";
    "MachServices" = {
        "com.github.GitHub.ShipIt" = mach-port-object;
    };
    "Label" = "com.github.GitHub.ShipIt";
    "TimeOut" = 30;
    "OnDemand" = true;
    "LastExitStatus" = 0;
    "Program" = "/Users/keith/Downloads/GitHub.app/Contents/Frameworks/Squirrel.framework/Resources/ShipIt";
    "ProgramArguments" = (
        "/Users/keith/Downloads/GitHub.app/Contents/Frameworks/Squirrel.framework/Resources/ShipIt";
        "com.github.GitHub.ShipIt";
    );
};

Nope 😕

[jspahrsummers]