Suggestion for install_gitlab

[robertdj]

There are currently some problems with install_gitlab as pointed out in this PR: #308

Furthermore, I am having problems downloading repos with a dot in the name. This is an issue in the GitLab REST API.

But there is another way of accessing repos on GitLab besides the path/to/repo: Every repo has a project id and according to the official docs this can be used instead of the path.

The id can be accessed from the "metadata" of the repo that is already downloaded as part of install_gitlab -- check e.g.
https://gitlab.com/api/v4/projects/jimhester%2Fcovr
https://gitlab.com/api/v4/projects/1486846
The number in the second URL is found in the first.

This metadata can be downloaded in both the problematic situations described above, so if the project id is extracted from the metadata and passed along to remote_download.gitlab_remote I think this would solve both problems.

[jimhester]

This sounds like an interesting idea, do you want to try a PR for this?

[robertdj]

Sure, I'll give it a try.

[robertdj]

After having looked more carefully in the code and the related issues it seems difficult/impossible to distinguish between subgroups and subdir from the repo path alone. (As others have concluded previously 😳)
Before going further I would like to hear your thoughts about how much install_gitlab can be changed?

Would it be okay to have a subdir argument like in install_github and drop support for subdir in the repo argument? This change alone would solve the problem with subgroups, but not for repos with dots.

[robertdj]

One more question:

Assuming the subdir / subgroup issue is fixed, there is still the problem of repos with a dot in the name.
In the cases I've tried, DESCRIPTION and the project metadata (in gitlab_commit) can be downloaded with the url encoded repo, but the archive.tar.gz cannot.
This can be fixed by using the project id instead of repo name.

I see two ways:

• Get the project id from the metadata that is already being downloaded in gitlab_commit. This would be a large change, since it affects install_remote that a lot of other install_*functions also use. install_remote relies on gitlab_commit through remote_sha to return the sha.
• Download the repo metadata twice -- one in gitlab_commit to get the sha and one to get the project id.

Do you have a preference?

[jimhester]

I would not want to change all the other install functions for this, so I think we have to get the metadata twice.

[robertdj]

Sounds good to me. What about subdir as an argument?