Add new artifact sgr-osx-x86_64.tgz
to releases, compiled with pyinstaller --onedir
, and default to it in install.sh
on Darwin
#656
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
todo:
follow-up PR:
sgr upgrade
works with multi-file executable mode (preferably in a backwards compatible way so existing OS X installations can move seamlessly from single-file to multi-file exec)install.sh
script works end to endSummary
sgr-osx-x86_64.tgz
sgr
, shared libraries, and resourcesDarwin
OS,install.sh
will:sgr-osx-x86_64.tgz
unless$FORCE_ONEFILE
is non-empty~/.splitgraph/pkg/sgr
(overwrite if exist)~/.splitgraph/sgr -> ~/.splitgraph/pkg/sgr/sgr
install.sh
[artifacts]
to build all artifacts but not release themWhy
The single-file executable performs poorly on Mac OS. Most noticeably,
every invocation of a single-file
sgr
starts with a 6-10 second delaywhile Apple verifies the binary (I think with
gatekeeper
). Whereaswith a multi-file
sgr
, only the first invocation has this delay,and all subsequent invocations are
< 1000ms
without any verificationoverhead.
The reason for this is because the act of verifying the binary
changes its headers in such a way that it needs to be re-verified
before the next invocation. At least, that's what I read in a GitHub
issue in one of the browser tabs that I've since closed.
How
osx_binary
workflow stage, add steps to build artifactsgr-osx/sgr.tgz
upload_release
workflow stage, releasesgr-osx/sgr.tgz
artifact assgr-osx-x86_64.tgz
splitgraph.spec
, when--onedir
is specified, use theCOLLECTION()
targetAlso
NO_PUBLISH
flag to.ci/build_wheel.sh
to not configure any PyPi parametersbuild_and_test
workflow stage, add step to build wheel without publishNote on using
pyinstaller
locally on Mac withpyenv
If developing
splitgraph.spec
and iterating withpyinstaller
, it helpsto have a local environment setup to closely simulate the CI environment,
so in general, try to match whatever steps the workflow is doing. Basically,
this is a summary of the gotchas:
bin/sgr
bin/sgr
--enable-framework
--enable-framework
, not--enable-shared
Here is a rough set of post-hoc notes of the commands I used to get
this working locally. It might be missing some details – make sure
after each time switching a virtualenv, that you're in the right one:
You can make sure that your Python installation was compiled with
the correct configuration flags by running the correct
python3-config
for your environment (unfortunately not exposed as
python3-config
bypyenv
):~/.pyenv/versions/3.7.12/bin/python3.7-config --cflags
The output should contain an include path that looks like:
Note on gatekeeper
Problem
If you download an artifact from Mac using a web browser, then
you will not be able to execute the artifact, whether downloaded
directly as
sgr-osx-x86_64
or extracted fromsgr-osx-x86_64.tgz
.This restriction does not apply when downloading a file with
curl
.Resolution
Since it only affects files downloaded from web browsers, it does not
affect the
install.sh
script, so that continues to be the recommendedinstallation method.
We could change
install.sh
to remove thecom.apple.quarantine
flagfrom the downloaded binary if it exists, but we don't expect it to
exist when downloading via
curl
, so it wouldn't make sense.We could join the Apple Developer Program and pay for the privilege
of signing executables with a certificate they will sign too.
We should add a note to each release, and should update the installation
documentation to warn about downloading binaries from a web browser.
Background
Background: On Mac, some files have "extra attributes" set. The
xattr
command can inspect and modify them. One of these attributes
is
com.apple.quarantine
, which web browsers set for any downloaded file.So if you use your web browser to download
sgr-osx-x86_64
fromthe releases page, then even after
chmod +x
, you will not beable to execute it. Attempts to execute the file will cause the OS
to render a pop-up window refusing to allow it.
Troubleshooting
com.apple.quarantine
and gatekeeperTo check if a file has the
com.apple.quarantine
bit set, runxattr $filename
,for example, to check the
sgr
executable in the local directory. If yousee
com.apple.quarantine
, it's set:You can remove it with the
-d
flag. If you remove the flag from a.tgz
archive,then none of the extracted files will have it set. If you do not remove it, then
all of the extracted files will each have it set:
You can recursively remove the flag on all files in a directory:
You can also inspect it further: