-
-
Notifications
You must be signed in to change notification settings - Fork 229
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
Master regression fixes #2481
Master regression fixes #2481
Conversation
Packages registered using add-path need to come before cached packages.
Hum that was done in 3c1c005 and I agree it wasn't a great idea. I'd be very happy with supporting more versions. The usage of the |
if (this.packagePath !is NativePath.init) | ||
this.scanPackageFolder(this.packagePath, mgr, existing); |
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.
The scan order shouldn't matter, the iteration order is done in getPackageIterator
, which IIUC is where you want to shift things.
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.
The problem is that both, search path packages and package path packages end up in the same array (fromPath
) and the order within this array matters.
Regarding the compile error, I'm not sure what exactly happens here, it obviously also works for the CI jobs, but not with the Windows version of LDC that I have installed (from the standard distribution ZIP file). |
Not sure what to do about this one, doesn't seem to be related to the changes. |
There's a spurious failure for this: #2345 |
Okay, all tests have passed after a re-run. |
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.
LGTM but the PackageManager
change could use a test to prevent future regression.
Why was it decided to drop all compiler support earlier than "ldc-latest" and "dmd-latest" (which doesn't explain why it didn't even compile on ldc-latest)? Having a buffer range of a few compiler versions greatly reduces friction during version transitions, not only in the build environment for dub itself, but also for dependencies of dub that might move slower. And IMHO using the latest shiny features, such as throw expressions in an infrastructure project like this is just utterly unnecessary. I think this really was a bad decision and should be revised, if possible. BTW, compiling with DMD 1.29.0 on Windows still produces backend errors due to some SumType.