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.
The text was updated successfully, but these errors were encountered:
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.
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.