2023-01-19 06:30:17 +08:00
|
|
|
.. Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
|
2018-10-08 04:52:23 +08:00
|
|
|
Spack Project Developers. See the top-level COPYRIGHT file for details.
|
|
|
|
|
|
|
|
|
|
SPDX-License-Identifier: (Apache-2.0 OR MIT)
|
|
|
|
|
|
2017-08-15 05:32:27 +08:00
|
|
|
.. _binary_caches:
|
|
|
|
|
|
2017-08-17 04:58:09 +08:00
|
|
|
============
|
2018-11-12 13:13:01 +08:00
|
|
|
Build Caches
|
2017-08-15 05:32:27 +08:00
|
|
|
============
|
|
|
|
|
|
|
|
|
|
Some sites may encourage users to set up their own test environments
|
2017-08-17 04:58:09 +08:00
|
|
|
before carrying out central installations, or some users may prefer to set
|
2017-08-15 05:32:27 +08:00
|
|
|
up these environments on their own motivation. To reduce the load of
|
|
|
|
|
recompiling otherwise identical package specs in different installations,
|
Refer to mirrors by name, path, or url (#34891)
With this change we get the invariant that `mirror.fetch_url` and
`mirror.push_url` return valid URLs, even when the backing config
file is actually using (relative) paths with potentially `$spack` and
`$env` like variables.
Secondly it avoids expanding mirror path / URLs too early,
so if I say `spack mirror add name ./path`, it stays `./path` in my
config. When it's retrieved through MirrorCollection() we
exand it to say `file://<env dir>/path` if `./path` was set in an
environment scope.
Thirdly, the interface is simplified for the relevant buildcache
commands, so it's more like `git push`:
```
spack buildcache create [mirror] [specs...]
```
`mirror` is either a mirror name, a path, or a URL.
Resolving the relevant mirror goes as follows:
- If it contains either / or \ it is used as an anonymous mirror with
path or url.
- Otherwise, it's interpreted as a named mirror, which must exist.
This helps to guard against typos, e.g. typing `my-mirror` when there
is no such named mirror now errors with:
```
$ spack -e . buildcache create my-mirror
==> Error: no mirror named "my-mirror". Did you mean ./my-mirror?
```
instead of creating a directory in the current working directory. I
think this is reasonable, as the alternative (requiring that a local dir
exists) feels a bit pendantic in the general case -- spack is happy to
create the build cache dir when needed, saving a `mkdir`.
The old (now deprecated) format will still be available in Spack 0.20,
but is scheduled to be removed in 0.21:
```
spack buildcache create (--directory | --mirror-url | --mirror-name) [specs...]
```
This PR also touches `tmp_scope` in tests, because it didn't really
work for me, since spack fixes the possible --scope values once and
for all across tests, so tests failed when run out of order.
2023-01-17 02:14:41 +08:00
|
|
|
installed packages can be put into build cache tarballs, pushed to
|
2017-08-17 04:58:09 +08:00
|
|
|
your Spack mirror and then downloaded and installed by others.
|
2017-08-15 05:32:27 +08:00
|
|
|
|
Refer to mirrors by name, path, or url (#34891)
With this change we get the invariant that `mirror.fetch_url` and
`mirror.push_url` return valid URLs, even when the backing config
file is actually using (relative) paths with potentially `$spack` and
`$env` like variables.
Secondly it avoids expanding mirror path / URLs too early,
so if I say `spack mirror add name ./path`, it stays `./path` in my
config. When it's retrieved through MirrorCollection() we
exand it to say `file://<env dir>/path` if `./path` was set in an
environment scope.
Thirdly, the interface is simplified for the relevant buildcache
commands, so it's more like `git push`:
```
spack buildcache create [mirror] [specs...]
```
`mirror` is either a mirror name, a path, or a URL.
Resolving the relevant mirror goes as follows:
- If it contains either / or \ it is used as an anonymous mirror with
path or url.
- Otherwise, it's interpreted as a named mirror, which must exist.
This helps to guard against typos, e.g. typing `my-mirror` when there
is no such named mirror now errors with:
```
$ spack -e . buildcache create my-mirror
==> Error: no mirror named "my-mirror". Did you mean ./my-mirror?
```
instead of creating a directory in the current working directory. I
think this is reasonable, as the alternative (requiring that a local dir
exists) feels a bit pendantic in the general case -- spack is happy to
create the build cache dir when needed, saving a `mkdir`.
The old (now deprecated) format will still be available in Spack 0.20,
but is scheduled to be removed in 0.21:
```
spack buildcache create (--directory | --mirror-url | --mirror-name) [specs...]
```
This PR also touches `tmp_scope` in tests, because it didn't really
work for me, since spack fixes the possible --scope values once and
for all across tests, so tests failed when run out of order.
2023-01-17 02:14:41 +08:00
|
|
|
Whenever a mirror provides prebuilt packages, Spack will take these packages
|
|
|
|
|
into account during concretization and installation, making ``spack install``
|
|
|
|
|
signficantly faster.
|
2017-08-15 05:32:27 +08:00
|
|
|
|
|
|
|
|
|
Refer to mirrors by name, path, or url (#34891)
With this change we get the invariant that `mirror.fetch_url` and
`mirror.push_url` return valid URLs, even when the backing config
file is actually using (relative) paths with potentially `$spack` and
`$env` like variables.
Secondly it avoids expanding mirror path / URLs too early,
so if I say `spack mirror add name ./path`, it stays `./path` in my
config. When it's retrieved through MirrorCollection() we
exand it to say `file://<env dir>/path` if `./path` was set in an
environment scope.
Thirdly, the interface is simplified for the relevant buildcache
commands, so it's more like `git push`:
```
spack buildcache create [mirror] [specs...]
```
`mirror` is either a mirror name, a path, or a URL.
Resolving the relevant mirror goes as follows:
- If it contains either / or \ it is used as an anonymous mirror with
path or url.
- Otherwise, it's interpreted as a named mirror, which must exist.
This helps to guard against typos, e.g. typing `my-mirror` when there
is no such named mirror now errors with:
```
$ spack -e . buildcache create my-mirror
==> Error: no mirror named "my-mirror". Did you mean ./my-mirror?
```
instead of creating a directory in the current working directory. I
think this is reasonable, as the alternative (requiring that a local dir
exists) feels a bit pendantic in the general case -- spack is happy to
create the build cache dir when needed, saving a `mkdir`.
The old (now deprecated) format will still be available in Spack 0.20,
but is scheduled to be removed in 0.21:
```
spack buildcache create (--directory | --mirror-url | --mirror-name) [specs...]
```
This PR also touches `tmp_scope` in tests, because it didn't really
work for me, since spack fixes the possible --scope values once and
for all across tests, so tests failed when run out of order.
2023-01-17 02:14:41 +08:00
|
|
|
.. note::
|
|
|
|
|
|
|
|
|
|
We use the terms "build cache" and "mirror" often interchangeably. Mirrors
|
|
|
|
|
are used during installation both for sources and prebuilt packages. Build
|
|
|
|
|
caches refer to mirrors that provide prebuilt packages.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
----------------------
|
|
|
|
|
Creating a build cache
|
|
|
|
|
----------------------
|
2017-08-15 05:32:27 +08:00
|
|
|
|
|
|
|
|
Build caches are created via:
|
|
|
|
|
|
2017-08-17 04:58:09 +08:00
|
|
|
.. code-block:: console
|
2017-08-15 05:32:27 +08:00
|
|
|
|
Refer to mirrors by name, path, or url (#34891)
With this change we get the invariant that `mirror.fetch_url` and
`mirror.push_url` return valid URLs, even when the backing config
file is actually using (relative) paths with potentially `$spack` and
`$env` like variables.
Secondly it avoids expanding mirror path / URLs too early,
so if I say `spack mirror add name ./path`, it stays `./path` in my
config. When it's retrieved through MirrorCollection() we
exand it to say `file://<env dir>/path` if `./path` was set in an
environment scope.
Thirdly, the interface is simplified for the relevant buildcache
commands, so it's more like `git push`:
```
spack buildcache create [mirror] [specs...]
```
`mirror` is either a mirror name, a path, or a URL.
Resolving the relevant mirror goes as follows:
- If it contains either / or \ it is used as an anonymous mirror with
path or url.
- Otherwise, it's interpreted as a named mirror, which must exist.
This helps to guard against typos, e.g. typing `my-mirror` when there
is no such named mirror now errors with:
```
$ spack -e . buildcache create my-mirror
==> Error: no mirror named "my-mirror". Did you mean ./my-mirror?
```
instead of creating a directory in the current working directory. I
think this is reasonable, as the alternative (requiring that a local dir
exists) feels a bit pendantic in the general case -- spack is happy to
create the build cache dir when needed, saving a `mkdir`.
The old (now deprecated) format will still be available in Spack 0.20,
but is scheduled to be removed in 0.21:
```
spack buildcache create (--directory | --mirror-url | --mirror-name) [specs...]
```
This PR also touches `tmp_scope` in tests, because it didn't really
work for me, since spack fixes the possible --scope values once and
for all across tests, so tests failed when run out of order.
2023-01-17 02:14:41 +08:00
|
|
|
$ spack buildcache create <path/url/mirror name> <spec>
|
2017-08-15 05:32:27 +08:00
|
|
|
|
Refer to mirrors by name, path, or url (#34891)
With this change we get the invariant that `mirror.fetch_url` and
`mirror.push_url` return valid URLs, even when the backing config
file is actually using (relative) paths with potentially `$spack` and
`$env` like variables.
Secondly it avoids expanding mirror path / URLs too early,
so if I say `spack mirror add name ./path`, it stays `./path` in my
config. When it's retrieved through MirrorCollection() we
exand it to say `file://<env dir>/path` if `./path` was set in an
environment scope.
Thirdly, the interface is simplified for the relevant buildcache
commands, so it's more like `git push`:
```
spack buildcache create [mirror] [specs...]
```
`mirror` is either a mirror name, a path, or a URL.
Resolving the relevant mirror goes as follows:
- If it contains either / or \ it is used as an anonymous mirror with
path or url.
- Otherwise, it's interpreted as a named mirror, which must exist.
This helps to guard against typos, e.g. typing `my-mirror` when there
is no such named mirror now errors with:
```
$ spack -e . buildcache create my-mirror
==> Error: no mirror named "my-mirror". Did you mean ./my-mirror?
```
instead of creating a directory in the current working directory. I
think this is reasonable, as the alternative (requiring that a local dir
exists) feels a bit pendantic in the general case -- spack is happy to
create the build cache dir when needed, saving a `mkdir`.
The old (now deprecated) format will still be available in Spack 0.20,
but is scheduled to be removed in 0.21:
```
spack buildcache create (--directory | --mirror-url | --mirror-name) [specs...]
```
This PR also touches `tmp_scope` in tests, because it didn't really
work for me, since spack fixes the possible --scope values once and
for all across tests, so tests failed when run out of order.
2023-01-17 02:14:41 +08:00
|
|
|
This command takes the locally installed spec and its dependencies, and
|
|
|
|
|
creates tarballs of their install prefixes. It also generates metadata files,
|
|
|
|
|
signed with GPG. These tarballs and metadata files are then pushed to the
|
|
|
|
|
provided binary cache, which can be a local directory or a remote URL.
|
2017-08-15 05:32:27 +08:00
|
|
|
|
Refer to mirrors by name, path, or url (#34891)
With this change we get the invariant that `mirror.fetch_url` and
`mirror.push_url` return valid URLs, even when the backing config
file is actually using (relative) paths with potentially `$spack` and
`$env` like variables.
Secondly it avoids expanding mirror path / URLs too early,
so if I say `spack mirror add name ./path`, it stays `./path` in my
config. When it's retrieved through MirrorCollection() we
exand it to say `file://<env dir>/path` if `./path` was set in an
environment scope.
Thirdly, the interface is simplified for the relevant buildcache
commands, so it's more like `git push`:
```
spack buildcache create [mirror] [specs...]
```
`mirror` is either a mirror name, a path, or a URL.
Resolving the relevant mirror goes as follows:
- If it contains either / or \ it is used as an anonymous mirror with
path or url.
- Otherwise, it's interpreted as a named mirror, which must exist.
This helps to guard against typos, e.g. typing `my-mirror` when there
is no such named mirror now errors with:
```
$ spack -e . buildcache create my-mirror
==> Error: no mirror named "my-mirror". Did you mean ./my-mirror?
```
instead of creating a directory in the current working directory. I
think this is reasonable, as the alternative (requiring that a local dir
exists) feels a bit pendantic in the general case -- spack is happy to
create the build cache dir when needed, saving a `mkdir`.
The old (now deprecated) format will still be available in Spack 0.20,
but is scheduled to be removed in 0.21:
```
spack buildcache create (--directory | --mirror-url | --mirror-name) [specs...]
```
This PR also touches `tmp_scope` in tests, because it didn't really
work for me, since spack fixes the possible --scope values once and
for all across tests, so tests failed when run out of order.
2023-01-17 02:14:41 +08:00
|
|
|
Here is an example where a build cache is created in a local directory named
|
|
|
|
|
"spack-cache", to which we push the "ninja" spec:
|
2021-06-15 12:46:27 +08:00
|
|
|
|
|
|
|
|
.. code-block:: console
|
|
|
|
|
|
Refer to mirrors by name, path, or url (#34891)
With this change we get the invariant that `mirror.fetch_url` and
`mirror.push_url` return valid URLs, even when the backing config
file is actually using (relative) paths with potentially `$spack` and
`$env` like variables.
Secondly it avoids expanding mirror path / URLs too early,
so if I say `spack mirror add name ./path`, it stays `./path` in my
config. When it's retrieved through MirrorCollection() we
exand it to say `file://<env dir>/path` if `./path` was set in an
environment scope.
Thirdly, the interface is simplified for the relevant buildcache
commands, so it's more like `git push`:
```
spack buildcache create [mirror] [specs...]
```
`mirror` is either a mirror name, a path, or a URL.
Resolving the relevant mirror goes as follows:
- If it contains either / or \ it is used as an anonymous mirror with
path or url.
- Otherwise, it's interpreted as a named mirror, which must exist.
This helps to guard against typos, e.g. typing `my-mirror` when there
is no such named mirror now errors with:
```
$ spack -e . buildcache create my-mirror
==> Error: no mirror named "my-mirror". Did you mean ./my-mirror?
```
instead of creating a directory in the current working directory. I
think this is reasonable, as the alternative (requiring that a local dir
exists) feels a bit pendantic in the general case -- spack is happy to
create the build cache dir when needed, saving a `mkdir`.
The old (now deprecated) format will still be available in Spack 0.20,
but is scheduled to be removed in 0.21:
```
spack buildcache create (--directory | --mirror-url | --mirror-name) [specs...]
```
This PR also touches `tmp_scope` in tests, because it didn't really
work for me, since spack fixes the possible --scope values once and
for all across tests, so tests failed when run out of order.
2023-01-17 02:14:41 +08:00
|
|
|
$ spack buildcache create --allow-root ./spack-cache ninja
|
|
|
|
|
==> Pushing binary packages to file:///home/spackuser/spack/spack-cache/build_cache
|
2021-06-15 12:46:27 +08:00
|
|
|
|
Refer to mirrors by name, path, or url (#34891)
With this change we get the invariant that `mirror.fetch_url` and
`mirror.push_url` return valid URLs, even when the backing config
file is actually using (relative) paths with potentially `$spack` and
`$env` like variables.
Secondly it avoids expanding mirror path / URLs too early,
so if I say `spack mirror add name ./path`, it stays `./path` in my
config. When it's retrieved through MirrorCollection() we
exand it to say `file://<env dir>/path` if `./path` was set in an
environment scope.
Thirdly, the interface is simplified for the relevant buildcache
commands, so it's more like `git push`:
```
spack buildcache create [mirror] [specs...]
```
`mirror` is either a mirror name, a path, or a URL.
Resolving the relevant mirror goes as follows:
- If it contains either / or \ it is used as an anonymous mirror with
path or url.
- Otherwise, it's interpreted as a named mirror, which must exist.
This helps to guard against typos, e.g. typing `my-mirror` when there
is no such named mirror now errors with:
```
$ spack -e . buildcache create my-mirror
==> Error: no mirror named "my-mirror". Did you mean ./my-mirror?
```
instead of creating a directory in the current working directory. I
think this is reasonable, as the alternative (requiring that a local dir
exists) feels a bit pendantic in the general case -- spack is happy to
create the build cache dir when needed, saving a `mkdir`.
The old (now deprecated) format will still be available in Spack 0.20,
but is scheduled to be removed in 0.21:
```
spack buildcache create (--directory | --mirror-url | --mirror-name) [specs...]
```
This PR also touches `tmp_scope` in tests, because it didn't really
work for me, since spack fixes the possible --scope values once and
for all across tests, so tests failed when run out of order.
2023-01-17 02:14:41 +08:00
|
|
|
Not that ``ninja`` must be installed locally for this to work.
|
2021-06-15 12:46:27 +08:00
|
|
|
|
Refer to mirrors by name, path, or url (#34891)
With this change we get the invariant that `mirror.fetch_url` and
`mirror.push_url` return valid URLs, even when the backing config
file is actually using (relative) paths with potentially `$spack` and
`$env` like variables.
Secondly it avoids expanding mirror path / URLs too early,
so if I say `spack mirror add name ./path`, it stays `./path` in my
config. When it's retrieved through MirrorCollection() we
exand it to say `file://<env dir>/path` if `./path` was set in an
environment scope.
Thirdly, the interface is simplified for the relevant buildcache
commands, so it's more like `git push`:
```
spack buildcache create [mirror] [specs...]
```
`mirror` is either a mirror name, a path, or a URL.
Resolving the relevant mirror goes as follows:
- If it contains either / or \ it is used as an anonymous mirror with
path or url.
- Otherwise, it's interpreted as a named mirror, which must exist.
This helps to guard against typos, e.g. typing `my-mirror` when there
is no such named mirror now errors with:
```
$ spack -e . buildcache create my-mirror
==> Error: no mirror named "my-mirror". Did you mean ./my-mirror?
```
instead of creating a directory in the current working directory. I
think this is reasonable, as the alternative (requiring that a local dir
exists) feels a bit pendantic in the general case -- spack is happy to
create the build cache dir when needed, saving a `mkdir`.
The old (now deprecated) format will still be available in Spack 0.20,
but is scheduled to be removed in 0.21:
```
spack buildcache create (--directory | --mirror-url | --mirror-name) [specs...]
```
This PR also touches `tmp_scope` in tests, because it didn't really
work for me, since spack fixes the possible --scope values once and
for all across tests, so tests failed when run out of order.
2023-01-17 02:14:41 +08:00
|
|
|
We're using the ``--allow-root`` flag to tell Spack that is OK when any of
|
|
|
|
|
the binaries we're pushing contain references to the local Spack install
|
|
|
|
|
directory.
|
2022-05-26 22:35:20 +08:00
|
|
|
|
Refer to mirrors by name, path, or url (#34891)
With this change we get the invariant that `mirror.fetch_url` and
`mirror.push_url` return valid URLs, even when the backing config
file is actually using (relative) paths with potentially `$spack` and
`$env` like variables.
Secondly it avoids expanding mirror path / URLs too early,
so if I say `spack mirror add name ./path`, it stays `./path` in my
config. When it's retrieved through MirrorCollection() we
exand it to say `file://<env dir>/path` if `./path` was set in an
environment scope.
Thirdly, the interface is simplified for the relevant buildcache
commands, so it's more like `git push`:
```
spack buildcache create [mirror] [specs...]
```
`mirror` is either a mirror name, a path, or a URL.
Resolving the relevant mirror goes as follows:
- If it contains either / or \ it is used as an anonymous mirror with
path or url.
- Otherwise, it's interpreted as a named mirror, which must exist.
This helps to guard against typos, e.g. typing `my-mirror` when there
is no such named mirror now errors with:
```
$ spack -e . buildcache create my-mirror
==> Error: no mirror named "my-mirror". Did you mean ./my-mirror?
```
instead of creating a directory in the current working directory. I
think this is reasonable, as the alternative (requiring that a local dir
exists) feels a bit pendantic in the general case -- spack is happy to
create the build cache dir when needed, saving a `mkdir`.
The old (now deprecated) format will still be available in Spack 0.20,
but is scheduled to be removed in 0.21:
```
spack buildcache create (--directory | --mirror-url | --mirror-name) [specs...]
```
This PR also touches `tmp_scope` in tests, because it didn't really
work for me, since spack fixes the possible --scope values once and
for all across tests, so tests failed when run out of order.
2023-01-17 02:14:41 +08:00
|
|
|
Once you have a build cache, you can add it as a mirror, discussed next.
|
2022-05-26 22:35:20 +08:00
|
|
|
|
2017-08-17 04:58:09 +08:00
|
|
|
---------------------------------------
|
2017-08-15 05:32:27 +08:00
|
|
|
Finding or installing build cache files
|
|
|
|
|
---------------------------------------
|
|
|
|
|
|
2017-08-17 04:58:09 +08:00
|
|
|
To find build caches or install build caches, a Spack mirror must be configured
|
|
|
|
|
with:
|
|
|
|
|
|
|
|
|
|
.. code-block:: console
|
|
|
|
|
|
Refer to mirrors by name, path, or url (#34891)
With this change we get the invariant that `mirror.fetch_url` and
`mirror.push_url` return valid URLs, even when the backing config
file is actually using (relative) paths with potentially `$spack` and
`$env` like variables.
Secondly it avoids expanding mirror path / URLs too early,
so if I say `spack mirror add name ./path`, it stays `./path` in my
config. When it's retrieved through MirrorCollection() we
exand it to say `file://<env dir>/path` if `./path` was set in an
environment scope.
Thirdly, the interface is simplified for the relevant buildcache
commands, so it's more like `git push`:
```
spack buildcache create [mirror] [specs...]
```
`mirror` is either a mirror name, a path, or a URL.
Resolving the relevant mirror goes as follows:
- If it contains either / or \ it is used as an anonymous mirror with
path or url.
- Otherwise, it's interpreted as a named mirror, which must exist.
This helps to guard against typos, e.g. typing `my-mirror` when there
is no such named mirror now errors with:
```
$ spack -e . buildcache create my-mirror
==> Error: no mirror named "my-mirror". Did you mean ./my-mirror?
```
instead of creating a directory in the current working directory. I
think this is reasonable, as the alternative (requiring that a local dir
exists) feels a bit pendantic in the general case -- spack is happy to
create the build cache dir when needed, saving a `mkdir`.
The old (now deprecated) format will still be available in Spack 0.20,
but is scheduled to be removed in 0.21:
```
spack buildcache create (--directory | --mirror-url | --mirror-name) [specs...]
```
This PR also touches `tmp_scope` in tests, because it didn't really
work for me, since spack fixes the possible --scope values once and
for all across tests, so tests failed when run out of order.
2023-01-17 02:14:41 +08:00
|
|
|
$ spack mirror add <name> <url or path>
|
2021-06-15 12:46:27 +08:00
|
|
|
|
|
|
|
|
|
Refer to mirrors by name, path, or url (#34891)
With this change we get the invariant that `mirror.fetch_url` and
`mirror.push_url` return valid URLs, even when the backing config
file is actually using (relative) paths with potentially `$spack` and
`$env` like variables.
Secondly it avoids expanding mirror path / URLs too early,
so if I say `spack mirror add name ./path`, it stays `./path` in my
config. When it's retrieved through MirrorCollection() we
exand it to say `file://<env dir>/path` if `./path` was set in an
environment scope.
Thirdly, the interface is simplified for the relevant buildcache
commands, so it's more like `git push`:
```
spack buildcache create [mirror] [specs...]
```
`mirror` is either a mirror name, a path, or a URL.
Resolving the relevant mirror goes as follows:
- If it contains either / or \ it is used as an anonymous mirror with
path or url.
- Otherwise, it's interpreted as a named mirror, which must exist.
This helps to guard against typos, e.g. typing `my-mirror` when there
is no such named mirror now errors with:
```
$ spack -e . buildcache create my-mirror
==> Error: no mirror named "my-mirror". Did you mean ./my-mirror?
```
instead of creating a directory in the current working directory. I
think this is reasonable, as the alternative (requiring that a local dir
exists) feels a bit pendantic in the general case -- spack is happy to
create the build cache dir when needed, saving a `mkdir`.
The old (now deprecated) format will still be available in Spack 0.20,
but is scheduled to be removed in 0.21:
```
spack buildcache create (--directory | --mirror-url | --mirror-name) [specs...]
```
This PR also touches `tmp_scope` in tests, because it didn't really
work for me, since spack fixes the possible --scope values once and
for all across tests, so tests failed when run out of order.
2023-01-17 02:14:41 +08:00
|
|
|
Both web URLs and local paths on the filesystem can be specified. In the previous
|
2021-06-15 12:46:27 +08:00
|
|
|
example, you might add the directory "spack-cache" and call it ``mymirror``:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.. code-block:: console
|
|
|
|
|
|
|
|
|
|
$ spack mirror add mymirror ./spack-cache
|
|
|
|
|
|
2017-08-15 05:32:27 +08:00
|
|
|
|
2021-06-15 12:46:27 +08:00
|
|
|
You can see that the mirror is added with ``spack mirror list`` as follows:
|
2017-08-15 05:32:27 +08:00
|
|
|
|
2017-08-17 04:58:09 +08:00
|
|
|
.. code-block:: console
|
2017-08-15 05:32:27 +08:00
|
|
|
|
|
|
|
|
|
2021-06-15 12:46:27 +08:00
|
|
|
$ spack mirror list
|
|
|
|
|
mymirror file:///home/spackuser/spack/spack-cache
|
|
|
|
|
spack-public https://spack-llnl-mirror.s3-us-west-2.amazonaws.com/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
At this point, you've create a buildcache, but spack hasn't indexed it, so if
|
|
|
|
|
you run ``spack buildcache list`` you won't see any results. You need to index
|
|
|
|
|
this new build cache as follows:
|
2017-08-15 05:32:27 +08:00
|
|
|
|
2017-08-17 04:58:09 +08:00
|
|
|
.. code-block:: console
|
2017-08-15 05:32:27 +08:00
|
|
|
|
Refer to mirrors by name, path, or url (#34891)
With this change we get the invariant that `mirror.fetch_url` and
`mirror.push_url` return valid URLs, even when the backing config
file is actually using (relative) paths with potentially `$spack` and
`$env` like variables.
Secondly it avoids expanding mirror path / URLs too early,
so if I say `spack mirror add name ./path`, it stays `./path` in my
config. When it's retrieved through MirrorCollection() we
exand it to say `file://<env dir>/path` if `./path` was set in an
environment scope.
Thirdly, the interface is simplified for the relevant buildcache
commands, so it's more like `git push`:
```
spack buildcache create [mirror] [specs...]
```
`mirror` is either a mirror name, a path, or a URL.
Resolving the relevant mirror goes as follows:
- If it contains either / or \ it is used as an anonymous mirror with
path or url.
- Otherwise, it's interpreted as a named mirror, which must exist.
This helps to guard against typos, e.g. typing `my-mirror` when there
is no such named mirror now errors with:
```
$ spack -e . buildcache create my-mirror
==> Error: no mirror named "my-mirror". Did you mean ./my-mirror?
```
instead of creating a directory in the current working directory. I
think this is reasonable, as the alternative (requiring that a local dir
exists) feels a bit pendantic in the general case -- spack is happy to
create the build cache dir when needed, saving a `mkdir`.
The old (now deprecated) format will still be available in Spack 0.20,
but is scheduled to be removed in 0.21:
```
spack buildcache create (--directory | --mirror-url | --mirror-name) [specs...]
```
This PR also touches `tmp_scope` in tests, because it didn't really
work for me, since spack fixes the possible --scope values once and
for all across tests, so tests failed when run out of order.
2023-01-17 02:14:41 +08:00
|
|
|
$ spack buildcache update-index ./spack-cache
|
2021-06-15 12:46:27 +08:00
|
|
|
|
|
|
|
|
Now you can use list:
|
|
|
|
|
|
|
|
|
|
.. code-block:: console
|
|
|
|
|
|
|
|
|
|
$ spack buildcache list
|
|
|
|
|
==> 1 cached build.
|
|
|
|
|
-- linux-ubuntu20.04-skylake / gcc@9.3.0 ------------------------
|
|
|
|
|
ninja@1.10.2
|
|
|
|
|
|
Refer to mirrors by name, path, or url (#34891)
With this change we get the invariant that `mirror.fetch_url` and
`mirror.push_url` return valid URLs, even when the backing config
file is actually using (relative) paths with potentially `$spack` and
`$env` like variables.
Secondly it avoids expanding mirror path / URLs too early,
so if I say `spack mirror add name ./path`, it stays `./path` in my
config. When it's retrieved through MirrorCollection() we
exand it to say `file://<env dir>/path` if `./path` was set in an
environment scope.
Thirdly, the interface is simplified for the relevant buildcache
commands, so it's more like `git push`:
```
spack buildcache create [mirror] [specs...]
```
`mirror` is either a mirror name, a path, or a URL.
Resolving the relevant mirror goes as follows:
- If it contains either / or \ it is used as an anonymous mirror with
path or url.
- Otherwise, it's interpreted as a named mirror, which must exist.
This helps to guard against typos, e.g. typing `my-mirror` when there
is no such named mirror now errors with:
```
$ spack -e . buildcache create my-mirror
==> Error: no mirror named "my-mirror". Did you mean ./my-mirror?
```
instead of creating a directory in the current working directory. I
think this is reasonable, as the alternative (requiring that a local dir
exists) feels a bit pendantic in the general case -- spack is happy to
create the build cache dir when needed, saving a `mkdir`.
The old (now deprecated) format will still be available in Spack 0.20,
but is scheduled to be removed in 0.21:
```
spack buildcache create (--directory | --mirror-url | --mirror-name) [specs...]
```
This PR also touches `tmp_scope` in tests, because it didn't really
work for me, since spack fixes the possible --scope values once and
for all across tests, so tests failed when run out of order.
2023-01-17 02:14:41 +08:00
|
|
|
With ``mymirror`` configured and an index available, Spack will automatically
|
|
|
|
|
use it during concretization and installation. That means that you can expect
|
|
|
|
|
``spack install ninja`` to fetch prebuilt packages from the mirror. Let's
|
|
|
|
|
verify by re-installing ninja:
|
2021-06-15 12:46:27 +08:00
|
|
|
|
|
|
|
|
.. code-block:: console
|
|
|
|
|
|
|
|
|
|
$ spack uninstall ninja
|
Refer to mirrors by name, path, or url (#34891)
With this change we get the invariant that `mirror.fetch_url` and
`mirror.push_url` return valid URLs, even when the backing config
file is actually using (relative) paths with potentially `$spack` and
`$env` like variables.
Secondly it avoids expanding mirror path / URLs too early,
so if I say `spack mirror add name ./path`, it stays `./path` in my
config. When it's retrieved through MirrorCollection() we
exand it to say `file://<env dir>/path` if `./path` was set in an
environment scope.
Thirdly, the interface is simplified for the relevant buildcache
commands, so it's more like `git push`:
```
spack buildcache create [mirror] [specs...]
```
`mirror` is either a mirror name, a path, or a URL.
Resolving the relevant mirror goes as follows:
- If it contains either / or \ it is used as an anonymous mirror with
path or url.
- Otherwise, it's interpreted as a named mirror, which must exist.
This helps to guard against typos, e.g. typing `my-mirror` when there
is no such named mirror now errors with:
```
$ spack -e . buildcache create my-mirror
==> Error: no mirror named "my-mirror". Did you mean ./my-mirror?
```
instead of creating a directory in the current working directory. I
think this is reasonable, as the alternative (requiring that a local dir
exists) feels a bit pendantic in the general case -- spack is happy to
create the build cache dir when needed, saving a `mkdir`.
The old (now deprecated) format will still be available in Spack 0.20,
but is scheduled to be removed in 0.21:
```
spack buildcache create (--directory | --mirror-url | --mirror-name) [specs...]
```
This PR also touches `tmp_scope` in tests, because it didn't really
work for me, since spack fixes the possible --scope values once and
for all across tests, so tests failed when run out of order.
2023-01-17 02:14:41 +08:00
|
|
|
$ spack install ninja
|
|
|
|
|
==> Installing ninja-1.11.1-yxferyhmrjkosgta5ei6b4lqf6bxbscz
|
|
|
|
|
==> Fetching file:///home/spackuser/spack/spack-cache/build_cache/linux-ubuntu20.04-skylake-gcc-9.3.0-ninja-1.10.2-yxferyhmrjkosgta5ei6b4lqf6bxbscz.spec.json.sig
|
|
|
|
|
gpg: Signature made Do 12 Jan 2023 16:01:04 CET
|
|
|
|
|
gpg: using RSA key 61B82B2B2350E171BD17A1744E3A689061D57BF6
|
|
|
|
|
gpg: Good signature from "example (GPG created for Spack) <example@example.com>" [ultimate]
|
|
|
|
|
==> Fetching file:///home/spackuser/spack/spack-cache/build_cache/linux-ubuntu20.04-skylake/gcc-9.3.0/ninja-1.10.2/linux-ubuntu20.04-skylake-gcc-9.3.0-ninja-1.10.2-yxferyhmrjkosgta5ei6b4lqf6bxbscz.spack
|
|
|
|
|
==> Extracting ninja-1.10.2-yxferyhmrjkosgta5ei6b4lqf6bxbscz from binary cache
|
|
|
|
|
==> ninja: Successfully installed ninja-1.11.1-yxferyhmrjkosgta5ei6b4lqf6bxbscz
|
|
|
|
|
Search: 0.00s. Fetch: 0.17s. Install: 0.12s. Total: 0.29s
|
|
|
|
|
[+] /home/harmen/spack/opt/spack/linux-ubuntu20.04-skylake/gcc-9.3.0/ninja-1.11.1-yxferyhmrjkosgta5ei6b4lqf6bxbscz
|
2021-06-15 12:46:27 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
It worked! You've just completed a full example of creating a build cache with
|
Refer to mirrors by name, path, or url (#34891)
With this change we get the invariant that `mirror.fetch_url` and
`mirror.push_url` return valid URLs, even when the backing config
file is actually using (relative) paths with potentially `$spack` and
`$env` like variables.
Secondly it avoids expanding mirror path / URLs too early,
so if I say `spack mirror add name ./path`, it stays `./path` in my
config. When it's retrieved through MirrorCollection() we
exand it to say `file://<env dir>/path` if `./path` was set in an
environment scope.
Thirdly, the interface is simplified for the relevant buildcache
commands, so it's more like `git push`:
```
spack buildcache create [mirror] [specs...]
```
`mirror` is either a mirror name, a path, or a URL.
Resolving the relevant mirror goes as follows:
- If it contains either / or \ it is used as an anonymous mirror with
path or url.
- Otherwise, it's interpreted as a named mirror, which must exist.
This helps to guard against typos, e.g. typing `my-mirror` when there
is no such named mirror now errors with:
```
$ spack -e . buildcache create my-mirror
==> Error: no mirror named "my-mirror". Did you mean ./my-mirror?
```
instead of creating a directory in the current working directory. I
think this is reasonable, as the alternative (requiring that a local dir
exists) feels a bit pendantic in the general case -- spack is happy to
create the build cache dir when needed, saving a `mkdir`.
The old (now deprecated) format will still be available in Spack 0.20,
but is scheduled to be removed in 0.21:
```
spack buildcache create (--directory | --mirror-url | --mirror-name) [specs...]
```
This PR also touches `tmp_scope` in tests, because it didn't really
work for me, since spack fixes the possible --scope values once and
for all across tests, so tests failed when run out of order.
2023-01-17 02:14:41 +08:00
|
|
|
a spec of interest, adding it as a mirror, updating its index, listing the contents,
|
2021-06-15 12:46:27 +08:00
|
|
|
and finally, installing from it.
|
|
|
|
|
|
Refer to mirrors by name, path, or url (#34891)
With this change we get the invariant that `mirror.fetch_url` and
`mirror.push_url` return valid URLs, even when the backing config
file is actually using (relative) paths with potentially `$spack` and
`$env` like variables.
Secondly it avoids expanding mirror path / URLs too early,
so if I say `spack mirror add name ./path`, it stays `./path` in my
config. When it's retrieved through MirrorCollection() we
exand it to say `file://<env dir>/path` if `./path` was set in an
environment scope.
Thirdly, the interface is simplified for the relevant buildcache
commands, so it's more like `git push`:
```
spack buildcache create [mirror] [specs...]
```
`mirror` is either a mirror name, a path, or a URL.
Resolving the relevant mirror goes as follows:
- If it contains either / or \ it is used as an anonymous mirror with
path or url.
- Otherwise, it's interpreted as a named mirror, which must exist.
This helps to guard against typos, e.g. typing `my-mirror` when there
is no such named mirror now errors with:
```
$ spack -e . buildcache create my-mirror
==> Error: no mirror named "my-mirror". Did you mean ./my-mirror?
```
instead of creating a directory in the current working directory. I
think this is reasonable, as the alternative (requiring that a local dir
exists) feels a bit pendantic in the general case -- spack is happy to
create the build cache dir when needed, saving a `mkdir`.
The old (now deprecated) format will still be available in Spack 0.20,
but is scheduled to be removed in 0.21:
```
spack buildcache create (--directory | --mirror-url | --mirror-name) [specs...]
```
This PR also touches `tmp_scope` in tests, because it didn't really
work for me, since spack fixes the possible --scope values once and
for all across tests, so tests failed when run out of order.
2023-01-17 02:14:41 +08:00
|
|
|
By default Spack falls back to building from sources when the mirror is not available
|
|
|
|
|
or when the package is simply not already available. To force Spack to only install
|
|
|
|
|
prebuilt packages, you can use
|
2021-06-15 04:17:35 +08:00
|
|
|
|
|
|
|
|
.. code-block:: console
|
|
|
|
|
|
Refer to mirrors by name, path, or url (#34891)
With this change we get the invariant that `mirror.fetch_url` and
`mirror.push_url` return valid URLs, even when the backing config
file is actually using (relative) paths with potentially `$spack` and
`$env` like variables.
Secondly it avoids expanding mirror path / URLs too early,
so if I say `spack mirror add name ./path`, it stays `./path` in my
config. When it's retrieved through MirrorCollection() we
exand it to say `file://<env dir>/path` if `./path` was set in an
environment scope.
Thirdly, the interface is simplified for the relevant buildcache
commands, so it's more like `git push`:
```
spack buildcache create [mirror] [specs...]
```
`mirror` is either a mirror name, a path, or a URL.
Resolving the relevant mirror goes as follows:
- If it contains either / or \ it is used as an anonymous mirror with
path or url.
- Otherwise, it's interpreted as a named mirror, which must exist.
This helps to guard against typos, e.g. typing `my-mirror` when there
is no such named mirror now errors with:
```
$ spack -e . buildcache create my-mirror
==> Error: no mirror named "my-mirror". Did you mean ./my-mirror?
```
instead of creating a directory in the current working directory. I
think this is reasonable, as the alternative (requiring that a local dir
exists) feels a bit pendantic in the general case -- spack is happy to
create the build cache dir when needed, saving a `mkdir`.
The old (now deprecated) format will still be available in Spack 0.20,
but is scheduled to be removed in 0.21:
```
spack buildcache create (--directory | --mirror-url | --mirror-name) [specs...]
```
This PR also touches `tmp_scope` in tests, because it didn't really
work for me, since spack fixes the possible --scope values once and
for all across tests, so tests failed when run out of order.
2023-01-17 02:14:41 +08:00
|
|
|
$ spack install --use-buildcache only <package>
|
2021-06-15 04:17:35 +08:00
|
|
|
|
|
|
|
|
For example, to combine all of the commands above to add the E4S build cache
|
|
|
|
|
and then install from it exclusively, you would do:
|
|
|
|
|
|
|
|
|
|
.. code-block:: console
|
|
|
|
|
|
|
|
|
|
$ spack mirror add E4S https://cache.e4s.io
|
|
|
|
|
$ spack buildcache keys --install --trust
|
Refer to mirrors by name, path, or url (#34891)
With this change we get the invariant that `mirror.fetch_url` and
`mirror.push_url` return valid URLs, even when the backing config
file is actually using (relative) paths with potentially `$spack` and
`$env` like variables.
Secondly it avoids expanding mirror path / URLs too early,
so if I say `spack mirror add name ./path`, it stays `./path` in my
config. When it's retrieved through MirrorCollection() we
exand it to say `file://<env dir>/path` if `./path` was set in an
environment scope.
Thirdly, the interface is simplified for the relevant buildcache
commands, so it's more like `git push`:
```
spack buildcache create [mirror] [specs...]
```
`mirror` is either a mirror name, a path, or a URL.
Resolving the relevant mirror goes as follows:
- If it contains either / or \ it is used as an anonymous mirror with
path or url.
- Otherwise, it's interpreted as a named mirror, which must exist.
This helps to guard against typos, e.g. typing `my-mirror` when there
is no such named mirror now errors with:
```
$ spack -e . buildcache create my-mirror
==> Error: no mirror named "my-mirror". Did you mean ./my-mirror?
```
instead of creating a directory in the current working directory. I
think this is reasonable, as the alternative (requiring that a local dir
exists) feels a bit pendantic in the general case -- spack is happy to
create the build cache dir when needed, saving a `mkdir`.
The old (now deprecated) format will still be available in Spack 0.20,
but is scheduled to be removed in 0.21:
```
spack buildcache create (--directory | --mirror-url | --mirror-name) [specs...]
```
This PR also touches `tmp_scope` in tests, because it didn't really
work for me, since spack fixes the possible --scope values once and
for all across tests, so tests failed when run out of order.
2023-01-17 02:14:41 +08:00
|
|
|
$ spack install --use-buildache only <package>
|
2021-06-15 04:17:35 +08:00
|
|
|
|
|
|
|
|
We use ``--install`` and ``--trust`` to say that we are installing keys to our
|
|
|
|
|
keyring, and trusting all downloaded keys.
|
|
|
|
|
|
|
|
|
|
|
2020-06-17 06:53:34 +08:00
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
List of popular build caches
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
|
|
|
|
* `Extreme-scale Scientific Software Stack (E4S) <https://e4s-project.github.io/>`_: `build cache <https://oaciss.uoregon.edu/e4s/inventory.html>`_
|
|
|
|
|
|
2017-08-17 04:58:09 +08:00
|
|
|
|
|
|
|
|
----------
|
2017-08-15 05:32:27 +08:00
|
|
|
Relocation
|
|
|
|
|
----------
|
|
|
|
|
|
2017-08-17 04:58:09 +08:00
|
|
|
Initial build and later installation do not necessarily happen at the same
|
|
|
|
|
location. Spack provides a relocation capability and corrects for RPATHs and
|
|
|
|
|
non-relocatable scripts. However, many packages compile paths into binary
|
|
|
|
|
artifacts directly. In such cases, the build instructions of this package would
|
2017-08-15 05:32:27 +08:00
|
|
|
need to be adjusted for better re-locatability.
|
|
|
|
|
|
2017-08-17 04:58:09 +08:00
|
|
|
.. _cmd-spack-buildcache:
|
2017-08-15 05:32:27 +08:00
|
|
|
|
2017-08-17 04:58:09 +08:00
|
|
|
--------------------
|
|
|
|
|
``spack buildcache``
|
|
|
|
|
--------------------
|
2017-08-15 05:32:27 +08:00
|
|
|
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
2017-08-17 04:58:09 +08:00
|
|
|
``spack buildcache create``
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
2017-08-15 05:32:27 +08:00
|
|
|
|
2017-08-17 04:58:09 +08:00
|
|
|
Create tarball of installed Spack package and all dependencies.
|
|
|
|
|
Tarballs are checksummed and signed if gpg2 is available.
|
|
|
|
|
Places them in a directory ``build_cache`` that can be copied to a mirror.
|
2017-10-27 02:06:59 +08:00
|
|
|
Commands like ``spack buildcache install`` will search Spack mirrors for build_cache to get the list of build caches.
|
2017-08-17 04:58:09 +08:00
|
|
|
|
|
|
|
|
============== ========================================================================================================================
|
|
|
|
|
Arguments Description
|
|
|
|
|
============== ========================================================================================================================
|
2017-10-27 02:06:59 +08:00
|
|
|
``<specs>`` list of partial specs or hashes with a leading ``/`` to match from installed packages and used for creating build caches
|
2017-08-17 04:58:09 +08:00
|
|
|
``-d <path>`` directory in which ``build_cache`` directory is created, defaults to ``.``
|
|
|
|
|
``-f`` overwrite ``.spack`` file in ``build_cache`` directory if it exists
|
|
|
|
|
``-k <key>`` the key to sign package with. In the case where multiple keys exist, the package will be unsigned unless ``-k`` is used.
|
|
|
|
|
``-r`` make paths in binaries relative before creating tarball
|
|
|
|
|
``-y`` answer yes to all create unsigned ``build_cache`` questions
|
|
|
|
|
============== ========================================================================================================================
|
|
|
|
|
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
``spack buildcache list``
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
|
|
|
|
Retrieves all specs for build caches available on a Spack mirror.
|
|
|
|
|
|
2017-10-27 02:06:59 +08:00
|
|
|
============== =====================================================================================
|
2017-08-17 04:58:09 +08:00
|
|
|
Arguments Description
|
2017-10-27 02:06:59 +08:00
|
|
|
============== =====================================================================================
|
|
|
|
|
``<specs>`` list of partial package specs to be matched against specs downloaded for build caches
|
|
|
|
|
============== =====================================================================================
|
2017-08-17 04:58:09 +08:00
|
|
|
|
|
|
|
|
E.g. ``spack buildcache list gcc`` with print only commands to install ``gcc`` package(s)
|
|
|
|
|
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
``spack buildcache install``
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
|
|
|
|
Retrieves all specs for build caches available on a Spack mirror and installs build caches
|
2017-10-27 02:06:59 +08:00
|
|
|
with specs matching the specs input.
|
2017-08-17 04:58:09 +08:00
|
|
|
|
2017-10-27 02:06:59 +08:00
|
|
|
============== ==============================================================================================
|
2017-08-17 04:58:09 +08:00
|
|
|
Arguments Description
|
2017-10-27 02:06:59 +08:00
|
|
|
============== ==============================================================================================
|
|
|
|
|
``<specs>`` list of partial package specs or hashes with a leading ``/`` to be installed from build caches
|
2017-08-17 04:58:09 +08:00
|
|
|
``-f`` remove install directory if it exists before unpacking tarball
|
|
|
|
|
``-y`` answer yes to all to don't verify package with gpg questions
|
2017-10-27 02:06:59 +08:00
|
|
|
============== ==============================================================================================
|
2017-08-17 04:58:09 +08:00
|
|
|
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
``spack buildcache keys``
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
|
|
|
|
List public keys available on Spack mirror.
|
|
|
|
|
|
|
|
|
|
========= ==============================================
|
|
|
|
|
Arguments Description
|
|
|
|
|
========= ==============================================
|
|
|
|
|
``-i`` trust the keys downloaded with prompt for each
|
|
|
|
|
``-y`` answer yes to all trust all keys downloaded
|
|
|
|
|
========= ==============================================
|