config: relax concurrent_packages to minimum 0#51840
Merged
Conversation
In the new installer, the number of concurrent packages is bound by `build_jobs`, and users don't have to bother setting `concurrent_packages` too. As a result, the new installer currently ignores `concurrent_packages`. In Spack v1.2 however, the new installer *will* respect `concurrent_packages` as an upper limit on the number of concurrent package installs. That makes the default value of `1` in config problematic. The suggestion is to use a default value of `0` from Spack v1.2 onwards, and make that a mean "default settings". For the old installer that means no package parallelism, for the new installer that means at most `build_jobs`. This commit allows the value `0` in config, and is primarily meant to be backported to ensure forward compatibilty with newer config files in older Spack version. Signed-off-by: Harmen Stoppels <[email protected]>
haampie
force-pushed
the
hs/fix/relax-parallel-processes-yaml
branch
from
b6ccd06 to
554ef3c
Compare
becker33
approved these changes
Jan 14, 2026
becker33
pushed a commit
that referenced
this pull request
Jan 14, 2026
In the new installer, the number of concurrent packages is bound by `build_jobs`, and users don't have to bother setting `concurrent_packages` too. As a result, the new installer currently ignores `concurrent_packages`. In Spack v1.2 however, the new installer *will* respect `concurrent_packages` as an upper limit on the number of concurrent package installs. That makes the default value of `1` in config problematic. The suggestion is to use a default value of `0` from Spack v1.2 onwards, and make that a mean "default settings". For the old installer that means no package parallelism, for the new installer that means at most `build_jobs`. This commit allows the value `0` in config, and is primarily meant to be backported to ensure forward compatibilty with newer config files in older Spack version. Signed-off-by: Harmen Stoppels <[email protected]>
becker33
pushed a commit
that referenced
this pull request
Jan 15, 2026
In the new installer, the number of concurrent packages is bound by `build_jobs`, and users don't have to bother setting `concurrent_packages` too. As a result, the new installer currently ignores `concurrent_packages`. In Spack v1.2 however, the new installer *will* respect `concurrent_packages` as an upper limit on the number of concurrent package installs. That makes the default value of `1` in config problematic. The suggestion is to use a default value of `0` from Spack v1.2 onwards, and make that a mean "default settings". For the old installer that means no package parallelism, for the new installer that means at most `build_jobs`. This commit allows the value `0` in config, and is primarily meant to be backported to ensure forward compatibilty with newer config files in older Spack version. Signed-off-by: Harmen Stoppels <[email protected]>
vjranagit
pushed a commit
to vjranagit/spack
that referenced
this pull request
Jan 18, 2026
In the new installer, the number of concurrent packages is bound by `build_jobs`, and users don't have to bother setting `concurrent_packages` too. As a result, the new installer currently ignores `concurrent_packages`. In Spack v1.2 however, the new installer *will* respect `concurrent_packages` as an upper limit on the number of concurrent package installs. That makes the default value of `1` in config problematic. The suggestion is to use a default value of `0` from Spack v1.2 onwards, and make that a mean "default settings". For the old installer that means no package parallelism, for the new installer that means at most `build_jobs`. This commit allows the value `0` in config, and is primarily meant to be backported to ensure forward compatibilty with newer config files in older Spack version. Signed-off-by: Harmen Stoppels <[email protected]>
becker33
pushed a commit
that referenced
this pull request
Jan 22, 2026
In the new installer, the number of concurrent packages is bound by `build_jobs`, and users don't have to bother setting `concurrent_packages` too. As a result, the new installer currently ignores `concurrent_packages`. In Spack v1.2 however, the new installer *will* respect `concurrent_packages` as an upper limit on the number of concurrent package installs. That makes the default value of `1` in config problematic. The suggestion is to use a default value of `0` from Spack v1.2 onwards, and make that a mean "default settings". For the old installer that means no package parallelism, for the new installer that means at most `build_jobs`. This commit allows the value `0` in config, and is primarily meant to be backported to ensure forward compatibilty with newer config files in older Spack version. Signed-off-by: Harmen Stoppels <[email protected]> Signed-off-by: Gregory Becker <[email protected]>
becker33
pushed a commit
that referenced
this pull request
Jan 26, 2026
In the new installer, the number of concurrent packages is bound by `build_jobs`, and users don't have to bother setting `concurrent_packages` too. As a result, the new installer currently ignores `concurrent_packages`. In Spack v1.2 however, the new installer *will* respect `concurrent_packages` as an upper limit on the number of concurrent package installs. That makes the default value of `1` in config problematic. The suggestion is to use a default value of `0` from Spack v1.2 onwards, and make that a mean "default settings". For the old installer that means no package parallelism, for the new installer that means at most `build_jobs`. This commit allows the value `0` in config, and is primarily meant to be backported to ensure forward compatibilty with newer config files in older Spack version. Signed-off-by: Harmen Stoppels <[email protected]> Signed-off-by: Gregory Becker <[email protected]>
Merged
becker33
pushed a commit
that referenced
this pull request
Feb 2, 2026
In the new installer, the number of concurrent packages is bound by `build_jobs`, and users don't have to bother setting `concurrent_packages` too. As a result, the new installer currently ignores `concurrent_packages`. In Spack v1.2 however, the new installer *will* respect `concurrent_packages` as an upper limit on the number of concurrent package installs. That makes the default value of `1` in config problematic. The suggestion is to use a default value of `0` from Spack v1.2 onwards, and make that a mean "default settings". For the old installer that means no package parallelism, for the new installer that means at most `build_jobs`. This commit allows the value `0` in config, and is primarily meant to be backported to ensure forward compatibilty with newer config files in older Spack version. Signed-off-by: Harmen Stoppels <[email protected]>
becker33
pushed a commit
that referenced
this pull request
Feb 2, 2026
In the new installer, the number of concurrent packages is bound by `build_jobs`, and users don't have to bother setting `concurrent_packages` too. As a result, the new installer currently ignores `concurrent_packages`. In Spack v1.2 however, the new installer *will* respect `concurrent_packages` as an upper limit on the number of concurrent package installs. That makes the default value of `1` in config problematic. The suggestion is to use a default value of `0` from Spack v1.2 onwards, and make that a mean "default settings". For the old installer that means no package parallelism, for the new installer that means at most `build_jobs`. This commit allows the value `0` in config, and is primarily meant to be backported to ensure forward compatibilty with newer config files in older Spack version. Signed-off-by: Harmen Stoppels <[email protected]> Signed-off-by: Gregory Becker <[email protected]>
becker33
pushed a commit
that referenced
this pull request
Feb 19, 2026
In the new installer, the number of concurrent packages is bound by `build_jobs`, and users don't have to bother setting `concurrent_packages` too. As a result, the new installer currently ignores `concurrent_packages`. In Spack v1.2 however, the new installer *will* respect `concurrent_packages` as an upper limit on the number of concurrent package installs. That makes the default value of `1` in config problematic. The suggestion is to use a default value of `0` from Spack v1.2 onwards, and make that a mean "default settings". For the old installer that means no package parallelism, for the new installer that means at most `build_jobs`. This commit allows the value `0` in config, and is primarily meant to be backported to ensure forward compatibilty with newer config files in older Spack version. Signed-off-by: Harmen Stoppels <[email protected]> Signed-off-by: Gregory Becker <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
In the new installer, the number of concurrent packages is bound by
build_jobs, and users don't have to bother settingconcurrent_packagestoo. As a result, the new installer currentlyignores
concurrent_packages.In Spack v1.2 however, the new installer will respect
concurrent_packagesas an upper limit on the number of concurrentpackage installs. That makes the default value of
1in configproblematic.
The suggestion is to use a default value of
0from Spack v1.2 onwards,and make that mean "default settings". For the old installer that is "no
package parallelism", for the new installer that is "at most
build_jobs".This commit allows the value
0in config, and is primarily meant to bebackported to ensure forward compatibilty with newer config files in
older Spack version.