Skip to content
This repository has been archived by the owner on Sep 4, 2018. It is now read-only.

Better heuristic for finding the .xcodeproj directory #471

Merged
merged 8 commits into from
Aug 23, 2016

Conversation

0xced
Copy link
Contributor

@0xced 0xced commented May 31, 2016

The "Make the Mac Great Again" plugin would not install because Alcatraz assumes that the .xcodeproj has the exact same name as the package. This may not be true, for example "Make the Mac Great Again" xcodeproj file is "MakeTheMacGreatAgain.xcodeproj" (without the spaces).

This new heuristic searches for all .xcodeproj and works fine if only one exists in the cloned directory.

I also refactor error handling for better diagnostics when things go wrong.

@0xced
Copy link
Contributor Author

0xced commented May 31, 2016

Ha, I should have looked at the pull requests first, #461 implements pretty much the same heuristic! But this pull request adds better error messages in addition to this new heuristic.

static NSString *const ATZInstallerErrorDomain = @"ATZInstallerErrorDomain";
NS_ENUM(NSInteger)
{
ATZInstallerXcodeProjectNotFoundError = 666,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔥 🔥 🔥

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kattrali is that good or bad fire? 😬

Copy link
Collaborator

@supermarin supermarin Jun 1, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@guillaume-algis @kattrali knows fires, she has the best fires!

@guillaumealgis
Copy link
Member

guillaumealgis commented Jun 1, 2016

Ha! It's really close to what I was doing with #461 indeed :)

#461 was stalled because I didn't take the time to test that all packages (color schemes and templates included) still installed fine after the change. Did you test your implementation on all packages?

In particular, I'm a bit worried that in your case installNameFromPbxproj: did not change that much (in contrast to efd7888#diff-b22b9cdae9c200d1c9d03235e2928944L148). But then it's not fresh in my mind, so maybe this works fine 👍.
My bad, did not see e8390db 🙂

Anyway, appart a few things (I'll comment inline), I'd be ok to merge your PR instead of #461 (if it's tested against all packages 😉).

[allXcodeProjFilenames addObject:directoryEntry];
}

if ([directoryEntry isEqualToString:@".git"]) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand the performance gain from skipping .git, but isn't it premature optimization? Did you encounter a real-world case where scanning the .git folder was a problem?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right, I changed it in 609b8f4.

@0xced
Copy link
Contributor Author

0xced commented Jun 2, 2016

I'd be ok to merge your PR instead of #461 (if it's tested against all packages 😉).

I’m not sure if you are serious or not. I don’t think testing against all packages will bring value. This PR is about getting more packages to install. If some are still failing to install after this PR is merged, we should handle the issues on a per package basis IMHO.

@guillaumealgis
Copy link
Member

@0xced So sorry if I wasn't clear. I am serious, but the goal is to ensure that we don't break the install process for the plugins which are already working today.

If some are still failing to install after this PR is merged, we should handle the issues on a per package basis IMHO.

Agreed!

@0xced
Copy link
Contributor Author

0xced commented Jun 2, 2016

the goal is to ensure that we don't break the install process for the plugins which are already working today

I took care of keeping the current behaviour of returning the .xcodeproj as soon as found if it has the same name as the package, so the risk of breaking existing packages is extremely low.

@supermarin
Copy link
Collaborator

Thanks for the contribution @0xced! 🍺

👍 when @guillaume-algis is ok to merge

@guillaumealgis
Copy link
Member

I hacked together an ugly script to install all packages on my machine. Will report tomorrow on the findings. Thanks for your patience @0xced!

@jurre
Copy link
Collaborator

jurre commented Jun 3, 2016

If anything, it would be nice to make sure that we install more packages correctly this way

@guillaumealgis
Copy link
Member

After merging this PR, the following packages will install correctly instead of failing:

  • Build Me Up
  • Fastlane-Plugin
  • Make the Mac Great Again
  • Refactor Code
  • XYZHappyCoding
  • ZLCheckFile

This does not break any plugin which previously installed, as expected 🎉

Full report here: https://gist.github.com/guillaume-algis/1da584f0964e94803056782394137e6e

One final thing before merging: I think this deserves a minor version number bump, not just a patch (I consider this to be more than just a bugfix), wdyt? 1.2.0?

@jurre
Copy link
Collaborator

jurre commented Jun 3, 2016

Great! Looks like a good improvement then. I agree on the version bump.

👍

@guillaumealgis
Copy link
Member

Hi @0xced, would you mind amending 47c562b with 1.2.0 instead of 1.1.19 and rebasing your branch onto master so we can merge this? 🍻
Thanks!

@0xced 0xced force-pushed the find-xcodeproj branch from 47c562b to 0690da8 Compare June 7, 2016 09:31
@0xced
Copy link
Contributor Author

0xced commented Jun 7, 2016

Done.

@guillaumealgis
Copy link
Member

guillaumealgis commented Jun 7, 2016

👍

Perfect, thank you!

Approved with PullApprove

@guillaumealgis
Copy link
Member

@jurre @kattrali @supermarin what do you think? LGTM?

@supermarin
Copy link
Collaborator

supermarin commented Aug 23, 2016

👍

Approved with PullApprove

@guillaumealgis
Copy link
Member

Thank you @supermarin!

@0xced do you mind rebasing on top of master once more? Thanks!

0xced added 8 commits August 23, 2016 23:30
The "Make the Mac Great Again" plugin would not install because Alcatraz assumes that the .xcodeproj has the exact same name as the package. This may not be true, for example "Make the Mac Great Again" xcodeproj file is "MakeTheMacGreatAgain.xcodeproj" (without the spaces).

This new heuristic searches for all .xcodeproj and works fine if only one exists in the cloned directory.
* Define constants for error domains and error codes
* Bubble up errors and present them to the user instead of just logging them
This is probably premature optimization, so better have smaller code.
@0xced
Copy link
Contributor Author

0xced commented Aug 23, 2016

Sure, I just rebased.

@guillaumealgis
Copy link
Member

guillaumealgis commented Aug 23, 2016

👍

Ugh. We need to re-approve. @supermarin ?

Edit: And the comment-parsing by pullapprove doesn't seems to work for some reason. I approved manually on pullapprove.com 🤔

@jurre
Copy link
Collaborator

jurre commented Aug 23, 2016

👍

Approved with PullApprove

@guillaumealgis guillaumealgis merged commit 665299f into alcatraz:master Aug 23, 2016
@0xced 0xced deleted the find-xcodeproj branch August 23, 2016 22:08
@guillaumealgis
Copy link
Member

Thanks @jurre ! 🙂

@jurre
Copy link
Collaborator

jurre commented Aug 23, 2016

Thanks @0xced and @guillaumealgis :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants