-
-
Notifications
You must be signed in to change notification settings - Fork 236
Respect skipRegistry value from configuration files #2903
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
Conversation
Currently, the skipRegistry value in configuration files is ignored, the final value is either the one the user passed on the command line, which is the intended behavior, or the value `none` if the user didn't pass a --skip-registry argument. This commit fixes this by introducing the new value `default_` to the SkippackageSuppliers enum to know when the user didn't pass the skip-registry argument and the value should be taken from the configuration files. Signed-off-by: Andrei Horodniceanu <[email protected]>
|
✅ PR OK, no changes in deprecations or warnings Total deprecations: 0 Total warnings: 0 Build statistics: statistics (-before, +after)
executable size=5364248 bin/dub
rough build time=64sFull build output |
| standard, /// Does not use the default package suppliers (`defaultPackageSuppliers`). | ||
| configured, /// Does not use default suppliers or suppliers configured in DUB's configuration file | ||
| all, /// Uses only manually specified package suppliers. | ||
| default_, /// The value wasn't specified. It is provided in order to know when it is safe to ignore it |
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.
Instead of modifying the enum, passing a Nullable would be a better option, wouldn't it ?
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.
When I wrote this I considered both passing a Nullable in the constructor or modifying the enum as possible solutions. My final conclusion was that I would rather not change the constructor semantics and, instead, modify the enum.
I wouldn't mind doing as you say and changing the approach to use a Nullable.
Instead of having a different enum value for stating that the value is not specified and it should be taken from the configuration files, use a Nullable. This has been suggested in dlang#2903 (comment) The main reason for this change is going through the other places where the configuration files were not honored (e.g. dub lint) (which was the intent of the original PR). It would be a shorter change to modify the current code to use the .default_ enum value when it was appropriate but if I have to change the code I might as well go and implement the less error-prone solution with Nullable. Signed-off-by: Andrei Horodniceanu <[email protected]>
Instead of having a different enum value for stating that the value is not specified and it should be taken from the configuration files, use a Nullable. This has been suggested in dlang#2903 (comment) The main reason for this change is going through the other places where the configuration files were not honored (e.g. dub lint) (which was the intent of the original PR). It would be a shorter change to modify the current code to use the .default_ enum value when it was appropriate but if I have to change the code I might as well go and implement the less error-prone solution with Nullable. Signed-off-by: Andrei Horodniceanu <[email protected]>
Instead of having a different enum value for stating that the value is not specified and it should be taken from the configuration files, use a Nullable. This has been suggested in dlang#2903 (comment) The main reason for this change is going through the other places where the configuration files were not honored (e.g. dub lint) (which was the intent of the original PR). It would be a shorter change to modify the current code to use the .default_ enum value when it was appropriate but if I have to change the code I might as well go and implement the less error-prone solution with Nullable. Signed-off-by: Andrei Horodniceanu <[email protected]>
Instead of having a different enum value for stating that the value is not specified and it should be taken from the configuration files, use a Nullable. This has been suggested in dlang#2903 (comment) The main reason for this change is going through the other places where the configuration files were not honored (e.g. dub lint) (which was the intent of the original PR). It would be a shorter change to modify the current code to use the .default_ enum value when it was appropriate but if I have to change the code I might as well go and implement the less error-prone solution with Nullable. Signed-off-by: Andrei Horodniceanu <[email protected]>
Instead of having a different enum value for stating that the value is not specified and it should be taken from the configuration files, use a Nullable. This has been suggested in #2903 (comment) The main reason for this change is going through the other places where the configuration files were not honored (e.g. dub lint) (which was the intent of the original PR). It would be a shorter change to modify the current code to use the .default_ enum value when it was appropriate but if I have to change the code I might as well go and implement the less error-prone solution with Nullable. Signed-off-by: Andrei Horodniceanu <[email protected]>
Currently, the skipRegistry value in configuration files is ignored, the final value is either the one the user passed on the command line, which is the intended behavior, or the value
noneif the user didn't pass a --skip-registry argument.This commit fixes this by introducing the new value
default_to the SkippackageSuppliers enum to know when the user didn't pass the skip-registry argument and the value should be taken from the configuration files.Be aware that the output of an invalid
skipRegistryvalue indub.settings.jsonhas changed:Before this PR:
After this PR: