stop existing, possibly in favor of briefcase

[glyph]

briefcase issues that would need to be resolved to kill Encrust completely:

• allow for bundling 3rd-party platform-specific frameworks (on macOS) beeware/briefcase#2180
  • this is needed to embed Sparkle, but perhaps Encrust could continue to exist as a thing that would automate running the thing to generate appcasts for me, since that is inherently platform-specific and fairly customized for me (Encrust doesn't have any code that would readily generalize to a more sophisticated release workflow yet)?
• investigate briefcase bundle size to see if it's a problem #10
  • I need to do my own investigating here to see if e.g. Pomodouroboros could exclude a few directories and get within throwing distance of its current bundle size
• Add plugin interface for custom build steps beeware/briefcase#2933
  • this is needed so that we can build Xib files while building the bundle (but is also probably generally useful for any resource preprocessing build step)

---

Already Completed

• overly aggressive restriction on bundle identifiers restricts my idiom beeware/briefcase#1212
• macOS apps aren't portable across x86_64/M1 unless all binary wheels are universal2 beeware/briefcase#1217
• maybe briefcase might hypothetically generate an archive invalid for notarization sometimes when using a zip archive for mac app distribution, and should probably use the recommended command to generate them beeware/briefcase#1218
• Parallelise calls to app signing beeware/briefcase#1201
• codesign --deep is deprecated and should be removed beeware/briefcase#1221
• Improve customizability of Apple code signing process beeware/briefcase#1291 — specifically the bit about custom Info.plist keys; right now both of my apps need at least LSUIElement, but likely will need more

[glyph]

maybe also need codesigning-without-building-using-briefcase documentation, but I gather this is already at least possible and maybe the docs even exist, need to read up on that before filing anything there

[freakboy3742]

FYI: beeware/briefcase#2110 (currently in review) resolves the last of your blockers. If there's anything else standing in the way of Briefcase adoption, let us know.

[glyph]

At this point I think this is going to start coming down to the features of py2app, rather than encrust itself. Is there a tutorial for anywhere to use briefcase just for codesigning and archiving, on an existing app bundle? It would be easier to adopt it a bit at a time.

[glyph]

Oh wait I guess I can't quite just use it for codesigning, because I would need some way to invoke the code in beeware/briefcase#1217 too, hmm.

[freakboy3742]

Yeah - you could probably trick Briefcase into thinking it had created the app, and so it could then sign it - but I wouldn't give any guarantees that any trick would be reliable in the long term - what you're describing definitely isn't an officially supported use case.

[glyph]

@freakboy3742 Trying to describe the major things that I think I'm still getting out of py2app.

[freakboy3742]

@glyph FYI- we've just added beeware/briefcase#2326, so you can now use Briefcase to sign and notarize a .app produced by py2app (or another tool).

[glyph]

FYI- we've just added beeware/briefcase#2326, so you can now use Briefcase to sign and notarize a .app produced by py2app (or another tool).

Awesome, thank you!

[glyph]

@freakboy3742 one thing that occurs to me here is that py2app runs ibtool on my .xib files for me. I don't really need this, but I do have to think about where it goes with respect to the rest of the build toolchain. Is this a thing that should live inside briefcase? Do you support plugins or something? I am reluctant to file an issue because it feels out of scope

[freakboy3742]

It sounds like it could be in scope. It would obviously be macOS specific, but I don't have any problem adding a macOS-specific part of the build process if the thing being added (a) is a common platform requirement, and (b) there's a meaningful, not-too-leaky abstraction that makes sense (e.g., "list of XIB files that need to be compiled", or "mapping of input XIB files to output file names"). XIB support definitely meets the requirements of (a); I haven't done enough work with standalone XIB files to know if there are other options that would need to be supported for (b).

As for plugins - yes, we very much support the idea of having plugins. Internally, most of the core functionality of Briefcase is built as plugins; the existence of macOS platform support is a "platform plugin" that just happens to be installed by default. Generally speaking, I would prefer to add a plugin interface that allows adding arbitrary features over trying to bake all possible functionality into Briefcase.

There isn't a plugin hook for pre/post build processing right now, but that would be an obvious hook to add. An analogous request was made as beeware/briefcase#436, to support PySide/Qt "compile resources" invocation. beeware/briefcase#1865 could potentially be implemented using a similar interface. If you squint enough, beeware/briefcase#2073 could even be implemented as a "post-build" hook - but that might make more sense to keep internally given that preferring to include, not include, or only include PYC content are mutually exclusive and exhaustive options.

If we do add built-in support for XIB file compilation, it would be preferable to implement it using a plugin interface so we can squash both feature requests at once.

[freakboy3742]

I've just coalesced those feature requests into a unified ticket (#2933).