Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

python3Packages.pyobjc: 7.0.1 -> 7.1 #118851

Closed
wants to merge 3 commits into from
Closed

python3Packages.pyobjc: 7.0.1 -> 7.1 #118851

wants to merge 3 commits into from

Conversation

lukegb
Copy link
Contributor

@lukegb lukegb commented Apr 8, 2021

Motivation for this change

The primary motivation is... that pyobjc doesn't actually build at master.

Below follows the commit message for python3Packages.pyobjc, but the individual commits have pretty lengthy commit messages that explain the rationale behind each of them.

At the same time, this actually fixes the build so it works at all; previously
it was both disabled on Python 3, and not working on Python 2.7.

pyobjc actually consists of a bunch of sub-modules (one for each wrapped
framework, give-or-take). For parallelising the build at maximum efficiency, as
well as allowing subpackages to select only the pyobjc dependencies which they
actually need, we package each of the submodules individually, rather than
pyobjc as a single coherent unit.

To make this easier, we use the GitHub src archive, and patch it once upfront,
which means we only need to move a single src pointer as we update (rather than
fetching from PyPI, which would entail having separate fetch directives for
each submodule).

Additional packaging notes:
* A lot of the exposed APIs are SDK-version-dependent, and nixpkgs takes great
  pains to expose separate frameworks from the SDK separately. In order for
  this to work, we patch out all the SDK version checks to instead use an
  environment variable with the macOS version, which we fix at 10.12 (which is,
  as of writing, the SDK version used).
* LaunchServices just appears to be broken, and this breaks importing the
  entire CoreServices module. That's patched too.
* iTunesLibrary is not actually a core macOS framework, but is usually provided
  in pyobjc. I don't want to delve into figuring out how to expose it properly
  as a framework, so for the purposes of getting a basic package up for review
  I've just dropped it.
* Given the large number of frameworks that are needed it's impractical to
  separately provide these as arguments to pyobjc, so the entire frameworks
  attrset is provided as an argument instead.
Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

GameCenter relies on GameCenterFoundation and GameCenterUI, which finally gives
the push needed to start checking and fixing the TBD reexports for TBD-only
frameworks.
pyobjc is effectively a bunch of Python bindings to a whole heap of the
frameworks in the Apple SDK - as such, we need to be able to declare
dependencies on a consistent set of frameworks as exposed by a particular macOS
SDK version.

Since the current SDK version fetched here is 10.12, this commit exports all
the frameworks that pyobjc expects for macOS 10.12.
At the same time, this actually fixes the build so it works at all; previously
it was both disabled on Python 3, and not working on Python 2.7.

pyobjc actually consists of a bunch of sub-modules (one for each wrapped
framework, give-or-take). For parallelising the build at maximum efficiency, as
well as allowing subpackages to select only the pyobjc dependencies which they
actually need, we package each of the submodules individually, rather than
pyobjc as a single coherent unit.

To make this easier, we use the GitHub src archive, and patch it once upfront,
which means we only need to move a single src pointer as we update (rather than
fetching from PyPI, which would entail having separate fetch directives for
each submodule).

Additional packaging notes:
* A lot of the exposed APIs are SDK-version-dependent, and nixpkgs takes great
  pains to expose separate frameworks from the SDK separately. In order for
  this to work, we patch out all the SDK version checks to instead use an
  environment variable with the macOS version, which we fix at 10.12 (which is,
  as of writing, the SDK version used).
* LaunchServices just appears to be broken, and this breaks importing the
  entire CoreServices module. That's patched too.
* iTunesLibrary is not actually a core macOS framework, but is usually provided
  in pyobjc. I don't want to delve into figuring out how to expose it properly
  as a framework, so for the purposes of getting a basic package up for review
  I've just dropped it.
* Given the large number of frameworks that are needed it's impractical to
  separately provide these as arguments to pyobjc, so the entire frameworks
  attrset is provided as an argument instead.

# Tests for -core don't run, and then the other tests don't work anyway.
doCheck = false;
#pythonImportsCheck = [ pythonModuleName ];
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I need to uncomment this before this is merged, whoops(!)

@lukegb
Copy link
Contributor Author

lukegb commented Apr 8, 2021

Ah, this'll have to go against staging since it touches the SDK bits.

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

Successfully merging this pull request may close these issues.

None yet

1 participant