-
Notifications
You must be signed in to change notification settings - Fork 153
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
reverted changes discussion #790
Comments
Sorry about that. Unfortunately devtools re-exports these functions and also includes a manual page for them, with the old signature. So they break I re-added the changes now to dev remotes, so that might solve the issue for you for now, but you'll need to keep using dev remotes. The devtools approach is not great, because that effectively means that we cannot change the signature of these functions. So either we'd need to change devtools first to remove the manual pages for the re-exported functions, or to dynamically generated docs in devtools. |
If the type signature is constrained, would it be easier to incorporate this change if it could be configured using a global option? Personally I try to avoid global state like this, but it might offer enough control while being a viable path within the bounds that |
@dgkf-roche is there any chance you could switch to using pak instead? |
@hadly Yeah, we're definitely looking in that direction. Up until recently we were limited by a few known bugs for private git and GitLab remotes, but those have both been patched in the dev version so we're just waiting for those to release. Beyond that known issue, this was a good nudge for us to look more closely at
|
Prioritization would be nice, but that's also not (really) implemented in remotes, which just does the same as
You can avoid Bioc with a flag: |
For installation, prioritizing specific repos this is something we can manage using
Ah, this is great to know. Then that should be sufficient for our needs, but does feel a bit like we're tricking
That's okay, and even preferred! Our goal is to ensure that it isn't used. In most (all?) cases we want to ignore this field. On rare occasion we'll check a package from a remote source. In these situations, we'd like to be more explicit about when and how any additional repositories might be used. |
Hi, I saw that some past contributions of mine (#783, #733) were reverted. The commit message mentions some issues with
devtools
, and I was hoping you could expand on this so that we can find an implementation that incorporates this feature while integrating nicely withdevtools
.For added background, this capability was contributed to support an enterprise use case which requires more precise control over the way that remote dependencies are prioritized. This is primarily to support situations where internal remote dependencies are used for development, but in production, we want to prioritize only published production packages from a CRAN-like internal repository.
We are open to contributing to devtools to address any breaking changes and make these changes possible, or iterating on the design of the feature if some aspect of it has proved to be problematic.
In the future, I would appreciate communication when contributions are being reverted, as our business process has already begun to anticipate the upcoming feature.
The text was updated successfully, but these errors were encountered: