-
-
Notifications
You must be signed in to change notification settings - Fork 230
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[stable] Fix #2973 #2974
base: stable
Are you sure you want to change the base?
[stable] Fix #2973 #2974
Conversation
✅ PR OK, no changes in deprecations or warnings Total deprecations: 8 Total warnings: 0 Build statistics: statistics (-before, +after)
-executable size=5293368 bin/dub
-rough build time=63s
+executable size=5297464 bin/dub
+rough build time=62s Full build output
|
source/dub/project.d
Outdated
@@ -563,7 +563,8 @@ class Project { | |||
(VersionRange range) { | |||
// See `dub.recipe.selection : SelectedDependency.fromYAML` | |||
assert(range.isExactVersion()); | |||
return m_packageManager.getPackage(dep.name, vspec.version_); | |||
auto tmp = m_packageManager.getPackage(basename, vspec.version_); | |||
return resolveSubPackage(tmp, subname, true); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This fixes the testcase in #2973. Not sure if this is the right fix though; PackageManager.getPackage()
returning the parent package when given a subpackage name doesn't make a lot of sense IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it doesn't make a lot of sense but it's always been this way. It was one of the things I wanted to fix when I introduced PackageName
but never got around to it.
For dependency resolution we always store references to parent package, not subpackage, because all subpackages should resolve to the same parent. I would need to inspect the code to see if that is really the right fix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay fine if it's always been like that.
@@ -98,7 +98,7 @@ version "1.0.0"`, PackageFormat.sdl); | |||
assert(dub.project.hasAllDependencies(), "project has missing dependencies"); | |||
assert(dub.project.getDependency("b", true), "Missing 'b' dependency"); | |||
assert(dub.project.getDependency("c", true), "Missing 'c' dependency"); | |||
assert(dub.project.getDependency("c", true), "Missing 'd' dependency"); | |||
assert(dub.project.getDependency("d", true), "Missing 'd' dependency"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just happened to notice this while browsing the tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! By when do you need this reviewed ?
source/dub/project.d
Outdated
@@ -563,7 +563,8 @@ class Project { | |||
(VersionRange range) { | |||
// See `dub.recipe.selection : SelectedDependency.fromYAML` | |||
assert(range.isExactVersion()); | |||
return m_packageManager.getPackage(dep.name, vspec.version_); | |||
auto tmp = m_packageManager.getPackage(basename, vspec.version_); | |||
return resolveSubPackage(tmp, subname, true); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it doesn't make a lot of sense but it's always been this way. It was one of the things I wanted to fix when I introduced PackageName
but never got around to it.
For dependency resolution we always store references to parent package, not subpackage, because all subpackages should resolve to the same parent. I would need to inspect the code to see if that is really the right fix.
I assume you've already reviewed this, and if you haven't, just expand the diff context - all other branches do the subpackage resolution (after getting the base package). :) - This is IMO a major release blocker, so v1.39 final should definitely have this. |
`{ "fileVersion": 1, "versions": { "b": "1.0.0" } }`); | ||
root.writePackageFile("b", "1.0.0", | ||
`{ "name": "b", "version": "1.0.0", "subPackages": [ { "name": "a" } ] }`); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Btw thx again for the test framework, sooo much better than the old tests...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wish we had a similar filesystem abstract in Phobos to make this kind of unittests the norm. It is so much more expressive.
I really need to finish it though, there's an issue with Windows at the moment which prevents mimicking the real world properly.
Do you know what introduced the regression ? I am fairly sure it used to work ? |
Oh, I thought this was all revamped after v1.38, but no, the 'problematic' line is the same as was in v1.38.0, which works for the original test case. Hmm... |
Hmm, this looks suspicious: dub/source/dub/packagemanager.d Lines 1740 to 1747 in 7a50f4c
It returns the package from the |
} | ||
|
||
return null; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've totally reworked the fix, tackling the PackageManager
API instead and resolving the subpackage in the lazy-loading getPackage()
case (that was the regression AFAICT), as well as newly in loadSCMPackage()
.
With more context now, I see that resolveSubPackage()
is actually to be avoided, as it results in a full packages scan, killing the lazy-loading advantages. It's still used if the dub.selections.json
contains a path-based selection, so with these current changes, we still get a full scan whenever depending on a subpackage of a path-selected parent package.
No description provided.