Skip to content
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

Dependency resolution problems #116

Open
1 of 2 tasks
brownag opened this issue Jan 20, 2023 · 1 comment
Open
1 of 2 tasks

Dependency resolution problems #116

brownag opened this issue Jan 20, 2023 · 1 comment

Comments

@brownag
Copy link
Member

brownag commented Jan 20, 2023

Simply checking that a package name is present in local library is not always enough to load the namespace.

Updating only "missing" packages can possibly result in complicated situations where all packages are present but cannot be loaded due to specific minimum versions set.

Most recently I saw this pop up on a users computer where raster namespace gets loaded via clhs, with raster now requiring terra >1.6-41... and the user had 1.6-17. Sometimes the dependencies are several steps removed and hard for users to figure out.

  • reportSetup() probably should default to updates of all required packages (change update=FALSE to update=TRUE)
  • Code used in mu-comparison report could be refactored and added to soilReports
    • to provide a standard routine for checking user has required packages (and giving informative errors of which namespaces don't load)
brownag added a commit that referenced this issue Jan 20, 2023
@brownag
Copy link
Member Author

brownag commented Feb 1, 2023

I just got burned by this today in the stat class--forgot to set update=FALSE for my demonstration.

We might want to develop a way to "pin" specific package versions within the manifests of report as part of the second TODO here. As we probably realized way back when, the default of upgrade=TRUE may be too sensitive to inconsequential version bumps... so the default could be "update if less than minimum required". Will think on this a bit to see if there is a more elegant way than entirely reinventing the current handling of this in DESCRIPTION files...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant