-
-
Notifications
You must be signed in to change notification settings - Fork 228
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
add some missing PackageName overloads #2867
Open
WebFreak001
wants to merge
1
commit into
dlang:master
Choose a base branch
from
WebFreak001:missing-packagename-overloads
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains 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
Oops, something went wrong.
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.
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 following will work:
Not ideal but
PackageName.this
is fairly light.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.
that really doesn't look like its intended API for how to iterate over selected packages though, selectedPackages should obviously just return PackageName[] instead - getSelectedVersion should only take as input what selectedPackages returns (string) - we don't want to encourage the library users to put PackageName(...) everywhere, it should just be constructed where explicitly needed, e.g. when converting from user input (string) to it. When it comes from the library it should be PackageName everywhere where applicable.
Also, while I toyed around with this tried to use PackageName everywhere, it quickly looked like an issue that PackageName.main also returns PackageName - we should probably have an extra type like RootPackageName that is not allowed to have any sub-package in it. (it can implicitly convert into PackageName though) Otherwise it can quickly become ambiguous and will quickly suffer from the same problems as using string everywhere. We should definitely add such a type before PackageName is rolled out as library part.
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.
Yes. Unfortunately we can't do overloads based on return type. Same reason why
Package.name
is stillstring
. This will be a v2 change. So the current state is IMO the best compromise. We could also just introduce an overload, e.g.byKey
, that returnsPackageName
.I hit a similar problem. In practice, dependency resolution barely cares about non-base/root package names because the version for subpackages is always the same. Likewise for
dub fetch
. But at least this is now somewhat visible / documented in the code. Note that the original version ofPackageName
returnedstring
formain
. It didn't work well.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.
there have already been backwards incompatible changes in this regard, so I'd suggest we just edit some things such as the selections and other places where it's obvious immediately and break this usage all at once instead of breaking parts of it every release.
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.
Where do we have backward incompatible changes ? I never intended to make breaking changes, that's why there are so many deprecated overloads in Dub ATM.
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.
ok sorry turned out it's just a single thing that I had to deal with, so it's not so bad, however it did need changes:
Package.getAllDependencies()
changed to PackageName without deprecation periodI really like the PackageName change and would like to use it in more places. My suggestion would be for more rarely used APIs to already change them to PackageName early.
Should package names inside the recipe struct be of type string or PackageName? PackageName implies semantics that it would have been checked already so I don't think it'd be the right thing that early on. Also we need a parse method that actually verifies the contents and some kind of fromTrustedString method that asserts on error, similar to the vibe.d APIs for stuff like paths.
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.
Let me have a look at it. It was a bit annoying to deal with
PackageDependency
when doing the migration, but I found a way to make it work. However, it might have been relying on thealias this
which I then removed...In general we should check user input as early as possible. Having it checked when parsing makes sense to me because we can then point the user to the right place. Configy has various hooks (
fromString
, constructor overloads) that it can call, and if they throw, it will display the error message with all the required information.For example:
This displays (with colors):
So it would be fairly trivial to do this change, however it's a breaking change. We are getting closer to a point where Dub 2.0 is inevitable and I'd prefer to pack the breaking changes for that moment.