spack does not handle multiple repos any more #5754
Comments
|
I' ve used git bisect to find the problem ( beware I' m a newbie on bisect.... first time ) and seems the problem shows up after commit |
|
@tgamblin Sorry, It seems to me the problem persist: Am I alone in using multiple repos or am I doing something basically wrong? Thanks in advance |
|
By trying and testing I found that this problem goes away by changing fullname to name in line 1198 of spec.py As I' ve not the slightest idea of what I' m doing, hope that someone shade some light on this. In case still work, will submit a PR |
|
I was just about to report the same problem. Reverting to commit db14987 seems to solve the problem, |
|
I think I see the issue here, although I'm not sure how it was triggered only recently. I'll open a PR in the next hour or so. |
Previously when RepoPath.repo_for_pkg was invoked with a string, it did not check if the string included a namespace. Any namespace-qualified package provided as a string would not be found (at which point the behavior was to return the highest-precedence repository).
|
Same issue here! |
|
Confirm that #5787 fix the issue, Thanks a lot @scheibelp |
This isn't a rework of the concretizer but it speeds things up a LOT.
The main culprits were:
1. Variant code, `provider_index`, and `concretize.py` were calling
`spec.package` when they could use `spec.package_class`
- `spec.package` looks up a package instance by `Spec`, which requires a
(fast-ish but not that fast) DAG compare.
- `spec.package_class` just looks up the package's class by name, and you
should use this when all you need is metadata (most of the time).
- not really clear that the current way packages are looked up is
necessary -- we can consider refactoring that in the future.
2. `Repository.repo_for_pkg` parses a `str` argument into a `Spec` when
called with one, via `@_autospec`, but this is not needed.
- Add some faster code to handle strings directly and avoid parsing
This speeds up concretization 3-9x in my limited tests. Still not super
fast but much more bearable:
Before:
- `spack spec xsdk` took 33.6s
- `spack spec dealii` took 1m39s
After:
- `spack spec xsdk` takes 6.8s
- `spack spec dealii` takes 10.8s
* Fixes #5754 Previously when RepoPath.repo_for_pkg was invoked with a string, it did not check if the string included a namespace. Any namespace-qualified package provided as a string would not be found (at which point the behavior was to return the highest-precedence repository). * handle nested namespaces for packages specified as strings in repo_for_pkg * add preliminary repository tests * add test which replicates #5754 * refactor repo tests with fixtures * define repo_path equivalent at test-level scope for repo tests * add tests for unknown namespace/package * rename fixture function (no longer prefixed with 'test_')
I had recently updated develop. I was using an additional repo.
Now this seem to prevent spack to work:
To reproduce:
cd /tmp
git clone https://github.com/LLNL/spack.git
cd spack
source share/spack/setup-env.sh
spack spec zlib
---------- WORK as expected ----------
spack repo create /tmp/goofy
spack repo add /tmp/goofy
spack spec zlib
==> Error: Invalid namespace for goofy repo: builtin
The text was updated successfully, but these errors were encountered: