Fix "spack install" when using Python 3.8 on macos#18205
Conversation
…ined function into a top-level function def
…e__ to be pickle-able
…to the child process
…le-level function
…ain__ from subprocess execution
This reverts commit 31373e7.
…gic from package.py to installer.py)
…t FD to child process FD table
…s to multiprocessing.Process
…aturely. Saving them in __init__ prevents this although I don't know why
…ferent entities attempt to close the same FD)
… the requirement to make Spec and all associated objects pickle-able)
…at the spec is passed as a dictionary rather than an object
This reverts commit 8a584d2.
…e applying updates related to installing the package (running the _writer_daemon process requires the environment that was used to start Spack itself)
df2d556 to
6bbb7de
Compare
|
@becker33 @tgamblin discussed changes are now complete:
@tldahlgren #18205 (comment) is now addressed. |
tgamblin
left a comment
There was a problem hiding this comment.
@scheibelp: I have a few very minor change requests.
|
@tgamblin all review comments are now addressed. I left #18205 (comment) unresolved because I only handled the part about changing the comment to clarify how things work on Windows. I did not do
because I think we already spoke about skipping this for now (I got the impression this was an old review comment because it was out of date before I made any edits). |
|
@adamjstewart #18205 (review) is now addressed |
|
Closing and reopening to kick off the tests that's wedged. |
As of #18205, all packages must be pickle-able to be installed by Spack. This adds a test to check that each package can be pickled. If any package fails to pickle, the test keeps going and collects the names of all failed packages; it then takes the first one that failed and attempts to re-pickle it, generating the full stack trace for the failed pickle attempt.
This fixes a logging error observed on macOS 11.0.1 (Big Sur). When performing a Spack install in debugging mode (e.g. `spack -d install py-scipy`) Spack is supposed to write a log of compiler wrapper command line invocations to the current working directory. Due to a regression error introduced by #18205, these files were no-longer generated, and Spack was printing errors such as "No such file or directory: None/." This is because the log file directory gets set from `spack.main.spack_working_dir`, but that variable is not set in the spawned process. This PR ensures that the working directory (at the time of the "spack install" invocation) is persisted to the subprocess.
This fixes a logging error observed on macOS 11.0.1 (Big Sur). When performing a Spack install in debugging mode (e.g. `spack -d install py-scipy`) Spack is supposed to write a log of compiler wrapper command line invocations to the current working directory. Due to a regression error introduced by spack#18205, these files were no-longer generated, and Spack was printing errors such as "No such file or directory: None/." This is because the log file directory gets set from `spack.main.spack_working_dir`, but that variable is not set in the spawned process. This PR ensures that the working directory (at the time of the "spack install" invocation) is persisted to the subprocess.
This object was introduced in spack#18124 which was later superseded by spack#18205 and removed any use if the object.
See: #14187
This is the same as #14187 but created as a branch of the main Spack repository to run additional CI checks.
Fixes #14102