-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
MacOS Mojave, Python 3.8: "AttributeError: Can't pickle local object 'fork.<locals>.child_process'" #14102
Comments
@scheibelp can you take a look at this? It looks like our unit tests are missing a Python 3.8 bug. |
This comment has been minimized.
This comment has been minimized.
I can replicate this using a Spack-installed Python 3.8.0 on Mac OS. I think the problem is that the implementation of Spack install wasn't following the requirements for pickling: in particular, there are locally-defined that are passed to I can fix the initial error with the changes at #14187 but that does not fully resolve this issue so I will need to work on it more over the next day or two. See also: |
Update: I've resolved some additional issues but more remain. I will be continuing with this in January. |
I figured I'll just add a (not very helpful) "I'm having this problem, too" comment here, with current |
This bug is sadly still a thing :/ |
@scheibelp we should bump this up in priority. Spack, MacPorts, and Anaconda all offer Python 3.8 installations. From what I can tell, the only reason Anaconda doesn't default to Python 3.8 is that a few packages still don't support it (TensorFlow being the big one), so as soon as that changes, I think the default version of Python any Anaconda user will have will be Python 3.8. I was also planning on switching Spack's default Python version to 3.8 once Anaconda makes the switch. Homebrew will likely follow. |
@adamjstewart I am taking a look at it myself, I am going to try to fix it, btw homebrew already switched. |
Did they? This formula still uses Python 3.7. |
Oh perhaps I got a package that made it build from "head" also: #16314 I updated some of the old patches by @scheibelp, however other issues occur after this. |
This is about to get bigger, since macOS Big Sur by Apple now ships with Python 3.8 by default, and most brew formulae has updated to Python 3.8 Space is still broken for me :/ |
Oddly enough, I've been using Spack on Ubuntu 20.04 (via WSL) which comes with Python 3.8.2 but I haven't encountered a single problem yet. I already have 160+ packages successfully installed. |
Spack should work fine with Python 3.8 in Linux, but not on Mac OS, because Python 3.8 multiprocessing behavior diverged for Mac OS and Linux. |
I'm starting to experience this issue as well. |
Just hit this with a fresh Catalina install using homebrew. Worked around by removing export PATH=/usr/bin:/bin:/usr/sbin:/sbin:$PATH |
@sethrj This solution doesn't seem ideal, if I remove /usr/local/bin from my path, then I can't access my Homebrew tools |
Sure, but you only need to do it temporarily in the shell in which you’re calling |
@DiegoMagdaleno You can also use |
Interesting, did brew roll out Python 3.8 in the last days or so (likely)? The problem occurs for me now as well in nightly macOS integration tests on Azure Pipelines (issue started July 22th). |
Nightly builds with MacOS started failing again due to an upgrade of the default virtual environment that now uses Python 3.8 This makes us hit spack#14102 and every build fails. This commit should be reverted along with the fix to spack#14102.
Actually, the problem disappears with conda environment activated. One more thing: |
@scheibelp add a PR #18124 I am an inexperienced user, switching from MacPorts. Hope the change doesn't introduce unintended consequences. |
FWIW Using pyenv is a good way to circumvent this issue until a long term fix is in place. Personally, I prefer that to unlinking the brew installation. |
The sooner this gets resolved, the sooner I can start recommending spack to mac people again... |
Spack creates a separate process to do package installation. Different operating systems and Python versions use different methods to create it but up until Python 3.8 both Linux and Mac OS used "fork" (which duplicates process memory, file descriptor table, etc.). Python >= 3.8 on Mac OS prefers creating an entirely new process (referred to as the "spawn" start method) because "fork" was found to cause issues (in other words "spawn" is the default start method used by multiprocessing.Process). Spack was dependent on the particular behavior of fork to replicate process memory and transmit file descriptors. This PR refactors the Spack internals to support starting a child process with the "spawn" method. To achieve this, it makes the following changes: - ensure that the package repository and other global state are transmitted to the child process - ensure that file descriptors are transmitted to the child process in a way that works with multiprocessing and spawn - make all the state needed for the build process and tests picklable (package, stage, etc.) - move a number of locally-defined functions into global scope so that they can be pickled - rework tests where needed to avoid using local functions This PR also reworks sbang tests to work on macOS, where temporary directories are deeper than the Linux sbang limit. We make the limit platform-dependent (macOS supports 512-character shebangs) See: #14102
In Python 3.8, local objects can't be pickled anymore which means we need to move that class definition to a top module level scope so it can be pickled by the multiprocess functionality. See https://gist.github.com/Kami/8386c79d2db7c95329e6c182ec639f49 and spack/spack#14102 for more details.
#818) * Fix copy manager functionality so it works under Python >= 3.8 on OS X. In Python 3.8, local objects can't be pickled anymore which means we need to move that class definition to a top module level scope so it can be pickled by the multiprocess functionality. See https://gist.github.com/Kami/8386c79d2db7c95329e6c182ec639f49 and spack/spack#14102 for more details. * Use Python 3.8 for osx unit tests on CI. * Don't run multiprocess copying manager tests on OSX since it doesn't work there under Python 3.8. * Add unit and smoke tests for python 3.8 Co-authored-by: arthur <arthurk@sentinelone.com>
I tried to install a package on MacOS Mojave using Python 3.8 installed from MacPorts. I got an error related to "pickle"ing an object.
The issue does not reproduce with Python 3.7. It reproduces on the latest commit of develop.
Steps to reproduce the issue
Error Message
Information on your system
This includes:
The text was updated successfully, but these errors were encountered: