Querying issues with project name yields warning

[famuvie]

Hi Sébastien, First of all, thanks for the work on {gitlabr}.

I'd like to report what it seems like an anomalous behaviour when querying issues of a public repository by project name, rather than id.

Here is a MRE:

## Works well, but with warning
my_issues <- gitlabr::gl_list_issues(
  project = "umr-astre/sit-design",
  api_root = "https://forgemia.inra.fr/api/v4/"
)
#> Warning in to_project_id(project, ...): NAs introduced by coercion

## Using project id instead of project name works without warning
## with the same results
my_project <- gitlabr::gl_get_project_id(
  project = "umr-astre/sit-design",
  api_root = "https://forgemia.inra.fr/api/v4/"
)
my_issues2 <- gitlabr::gl_list_issues(
  project = my_project,
  api_root = "https://forgemia.inra.fr/api/v4/"
)
identical(my_issues, my_issues2)
#> [1] TRUE

^{Created on 2021-09-27 by the reprex package (v2.0.1)}

[famuvie]

I could not figure out where was the problem. But here is a traceback, in case is of any use:

> gitlabr::gl_list_issues(
+   project = "umr-astre/sit-design",
+   api_root = "https://forgemia.inra.fr/api/v4/"
+ )
Error in to_project_id(project, ...) : 
  (converted from warning) NAs introduced by coercion

Enter a frame number, or 0 to exit   

 1: gitlabr::gl_list_issues(project = "umr-astre/sit-design", api_root
 2: (if (!missing(project) && is.null(project)) "issues" else gl_proj_
 3: iffn(., is.null(issue_id), function(issue) {
    issue %>% unlist(r
 4: gitlab(., ...)
 5: req %>% paste(collapse = "/") %>% prefix(api_root, "/") %T>% iff(d
 6: iff(., debug, function(x) {
    print(paste(c("URL:", x, " ", "quer
 7: prefix(., api_root, "/")
 8: paste0(..., text)
 9: paste(., collapse = "/")
10: gl_proj_req(project, req = c("issues", issue_id), ...)
11: to_project_id(project, ...)
12: .signalSimpleWarning("NAs introduced by coercion", base::quote(to_
13: withRestarts({
    .Internal(.signalCondition(simpleWarning(msg, ca
14: withOneRestart(expr, restarts[[1]])
15: doWithOneRestart(return(expr), restart)

[statnmap]

Hi Facundo,

The project name is supposed to be the name of the repository only. Not user/repo.

However, using project name in gitlab.com is not a good idea because {gitlabr} will try to match the name with all name of repositories that you have access to. If your project is not listed in the 3 first pages of Gitlab.com total list of projects, then, {gitlabr} will not find it. This means it can also find another project with the same name...

Thus, the best solution is always the id number of the project.

Maybe, the search function could include the user, group or something else, but with big public repositories, that may be difficult and long to retrieve your project. But for now, I will let the package as is.

At least, if the output is NA, we could add a message / stop informing that "the project was not found in the list of repositories available. This may mean that there are too much repositories available to you. Please provide the id number of your project instead"

[famuvie]

Hi, thanks for the answer. Ok, I got that the project name should not include the namespace and that gitlabr will search through the namespaces that are accessible to me (although this risks facing name clashes). But even then:

• Why gl_get_project_id found the project correctly while gl_list_issues yielded a warning (even though it also found the project correctly).
• If I use the project name without the namespace, the MRE still holds and behaves in the same way.

I'm ok with using the project id systematically. But perhaps this could be made more clear in the documentation. Currently, the argument project for gl_list_issues() reads:

project name or id, ...

On the other hand, for a single query of the issues, it feels a little tedious to give the api_root for getting the project id and then a second time to gather the list of issues.

Best wishes ƒacu.-

[statnmap]

The documentation needs some refactoring. I already stated in the README that the ID was the preferred way. If you want to propose some PR to update the documentation, I'll be happy to review it.

I am not sure I fully understand your remark about the api_root though.

[statnmap]

• The function for matching id now returns a stop or a warning if nothing matched, so that users know why it stopped.
  

• I changed documentation to encourage users to use the id, I hope this will help.

#' @param project id (preferred way) or name of the project.

• The function now allows searching for project with namespace

• The function also look for projects the user is member of, to increase chances to find the project

  if (is.null(list(...)$membership)) {
    # Get a list of projects the authenticated user is a member of
    # To increase the chances of finding the project
    req_member <- gitlab(
      req = "projects", ..., simple = TRUE,
      membership = TRUE
    )
    req <- bind_rows(req, req_member) %>% distinct()
  }

I think it'll be easier now.