Repository navigation
group transfer-project is confusing #1529
Description
Description of the problem, including code/CLI snippet
I've wrapped the python gitlab CLI in some powershell tooling
Relevant snippet:
function Move-GitLabProject {
[CmdletBinding()]
param (
[Parameter(Position=0, Mandatory=$true)]
[string]
$ProjectId,
[Parameter(Position=1, Mandatory=$true)]
[string]
$DestinationGroup,
[switch]
[Parameter(Mandatory=$false)]
$WhatIf = $false
)
$SourceProject = Get-GitLabProject -ProjectId $ProjectId
$Group = Get-GitLabGroup -GroupId $DestinationGroup
if ($WhatIf) {
Write-Host "WhatIf: Moving '$($SourceProject.Name)' (project id: $($SourceProject.Id)) to '$($Group.FullPath)' (group id: $($Group.Id))"
} else {
gitlab group transfer-project --id $Group.Id --to-project-id $SourceProject.Id
}
}Expected Behavior
Recommend that the parameters be renamed:
--id -> --to-group-id
--to-project-id -> --project-id
traditionally, to denotes a destination, not a source.
Actual Behavior
Trial and error and code inspection before realizing I had the parameters backwards.
Specifications
- python-gitlab version: 2.8.0
- API version you are using (v3/v4): v4
- Gitlab server version (or gitlab.com): 13.10.3 (Enterprise Edition)
Activity
nejch commentedon Jun 23, 2021
I agree
--to-project-idshould be changed, that's strange. But for the group ID, this is picked up from the parent command, as you use thegroupobject, so it is a little more consistent with other subcommands if we leave it as is IMO.Perhaps a less confusing option here would be to use the subcommand of the
projectobject, which is the first thing that comes to mind when I think about transferring projects actually. This has hopefully clearer arguments (the--to-namespacearg is almost exactly what you ask for but also includes personal namespaces):https://python-gitlab.readthedocs.io/en/stable/cli-objects.html#gitlab-project-transfer-project
[-]Transfer project is confusing[/-][+]`group transfer-project` is confusing[/+]Use the more natural project semantics for transfer
chris-peterson commentedon Jun 23, 2021
Makes sense to leave
--idalone since there's strong precedent for it being scoped to the parent command.You were right that switching to the
projectvariant is much cleaner.Perhaps the
groupCLI option should just be deprecated rather than renaming anything.nejch commentedon Jun 23, 2021
Great! I think we can keep the group one as otherwise people will request it since it's available in the API:
https://docs.gitlab.com/ee/api/groups.html#transfer-project-to-group
But maybe we can more closely follow the params in the API (
project_id). Sometimes GitLab endpoints are kind of duplicated like that. Neat little idea for the project btw, I've always thought creating a toolkit-style higher-level wrapper (in python though) would be a good idea for functions/commands that we all reinvent everywhere when using python-gitlab.