WIP, ENH: Support relative mirror paths#13213
WIP, ENH: Support relative mirror paths#13213tylerjereddy wants to merge 3 commits intospack:developfrom
Conversation
becker33
left a comment
There was a problem hiding this comment.
I don't think this fixes #12710. The issue asked for a way to vendor tarballs in an environment, relative to the environment yaml file. Using the working directory is only the same as the directory of the environment for directory-based environments, not for Spack-managed environments.
One way to make this work could be to have spack environments automatically change working directory to the location of their yaml files. Do you think that's a feasible addition to this PR?
* add a regression test that fails on development branch for the handling of relative mirror paths
* add support for fetching from relative mirrors paths * minor whitespace cleanup for flake8 check in the cognate unit test
* add documentation for Spack relative mirror path support * test_mirror_paths() now requires fetching to be possible for a variety of spack working directories; this aims to enforce usage of a single path relative to the yaml file, instead of a fragile path relative to the spack working directory at the time of mirror addition * adjust source code to properly handle addition of relative mirror paths added via spack.config.set() in test_mirror_paths; all relative paths are now adjusted such that they are relative to the yaml file location * test_mirror_paths() also adjusted to require handling of relative paths prefixed with "file://" and not prefixed in that way, for consistency with absolute path handling; adjust source code to handle this * test_mirror_paths() was adjusted to probe the code path that directly leverages "spack mirror add" via subprocess (no additional failures were observed, so we may be able to forego this); same for addition of a mirror via a custom file created in a custom scope * test_mirror_paths() now checks for additional indicators of fetching problems, including usage of external (http) and local (cache) sources that would circumvent the code paths
816ceee to
da8acac
Compare
|
The PR has been revised substantially based on the feedback above. See the new docs in the PR for how it currently works. I'll wait for more feedback after these changes, but I do note that:
|
|
Any feedback on the revised version of this PR? |
|
I'm closing this now that #34891 is merged, as well as other PRs that ensures Spack uses |
Fixes #12710 cc @AndrewGaspar @junghans
A number of things to discuss / review carefully here if core devs decide this is a good idea:
~/.spack/...when not working there, unless you edit the yaml file manually); so some design decisions to be made therefile://currently remains, even for the relative filepath support, presumably for thecurlfeed-through