Allow other pkg versions besides most recent version

[marlycormar]

Fix versioning number

• [ ] The version dropdown should display the version(s) uploaded by the user (not the most recent one of the package).
• [ ] The db should be able to store different versions of the same package. Hence, some tables (like the Packageinfo one) should be modified accordingly (e.g. Packageinfo should have a primary key - package name - and a secondary key - package version). The update and insert may need to be updated.

[ghost]

How can we tell if the version provided in the *.csv file is not mistyped? Can we assume the version uploaded by the user is the one they have installed? Or do we need to pull the version history out of CRAN?

[ghost]

Overall plan:

• [ ] Given uploadpackage.R reads *.csv file into df pkgs_file
• [ ] Verify that the package name exists on CRAN
• [ ] Verify that the version exists and is available using the versions package function available.versions()
• [ ] If either test fails, issue message and delete the row in pkgs_file and reset the row numbers
• [ ] Otherwise, continue but with the following changes.
• [ ] Multiple versions per package will be allowed, not just the latest one.
• [ ] Version dropdown in sidebar will display the version(s) uploaded by the user.

[ghost]

In dbupload.R, information on the latest version is web-scraped.

        read_html(paste0(
          "https://cran.r-project.org/web/packages/",
          package_name
        ))

However, if the package_version read is not equal to the current version, we can do something else if (ver != package_version) signalCondition(e) and use the R6Class function description() to get information about the package that is currently installed

          if (file.exists(paste(i, "/", package_name, sep = "")) == TRUE) {
            i <- paste0(i, "/", package_name)
            d <- description$new(i)
            title <- d$get("Title")
            ver <- d$get("Version")
            desc <- d$get("Description")
            desc <- gsub("'", "", desc) # remove single quotes
            main <- d$get("Maintainer")
            auth <- d$get("Author")
            lis <- d$get("License")
            pub <- d$get("Packaged")

So it is possible to have more than one version of a package.

and, at least, the overall package information is different for each version

[ghost]

I can make all the comments specific to a version, and since the Community usage metrics runs across versions, I can show the information up to the version selected.

[ghost]

Right now the only issue I see is that maintenance metrics (and testing metrics) is derived from the riskmetric pkg_ref() function which retrieves the version using utils::packageVersion if the package is locally installed. Maybe we can modify the version that gets passed to pkg_assess()?

  package_riskmetric1 <<-
    pkg_ref(package_name) %>%
    as_tibble() %>%
    pkg_assess() %>%
    pkg_score() %>%
    mutate(risk = summarize_scores(.))

[Jeff-Thompson12]

@AARON-CLARK Is this still something we are looking to implement? Since we are pulling in remote sources for {riskmetric}, for each assessment it only makes sense to use the most recent version. The only time I can personally think of where this might matter is on reassessments, but you wouldn't be able to retroactively score an older version.

[AARON-CLARK]

• [ ] The version dropdown should display the version(s) uploaded by the user (not the most recent one of the package).
• [ ] The db should be able to store different versions of the same package. Hence, some tables (like the Packageinfo one) should be modified accordingly (e.g. Packageinfo should have a primary key - package name - and a secondary key - package version). The update and insert may need to be updated.

@Jeff-Thompson12, I can understand why we may want to close this issue, and maybe we should BUT I think we could still pursue something similar to tracking pkg version in the app if we adjust our tune a little here. Just looking at our original tasks on this issue, what if we replace all instances of the word "version" with "pkg assessment date"? Then at each assessment date, we could record what the version was at that time. That would be the closest thing we could do to versioning, helping us with #253 (kind of... it's step 1) and #486.

Thoughts?

[Jeff-Thompson12]

Seems plausible but we probably need to start a new brainstorming issue. Implementation would require some form of comparison module. This would also potentially require changes in the database that wouldn't be backward compatible, but that was true with versioning as well.

[AARON-CLARK]

@Jeff-Thompson12, I agree with everything you just said. Do you want to raise a new issue?

Also, comparison module would be fantastic, but it doesn't have to be apart of step 1. It could come in a later PR. Note there is already an open issue for that topic (#254... and it was mentioned in #253 too).

I feel like step 1 is just setting up the database to store info based on pkg & assessment date and allowing the app to retrieve / toggle between different assessment dates. Obviously, displaying the assessment date more prominently will be a big part of that.

Step 2: comparison module.

Step 3: maybe more snapshotting features, like viewing pkgs by assessment dates (assuming lots of pkgs were all assessed/ re-assessed at once). Perhaps automation suggested here? Who knows.

Step 4: tacos?

[aclark02-arcus]

closing in favor of #534