`group transfer-project` is confusing · Issue #1529 · python-gitlab/python-gitlab · GitHub

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)

I agree --to-project-id should be changed, that's strange. But for the group ID, this is picked up from the parent command, as you use the group object, 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 project object, which is the first thing that comes to mind when I think about transferring projects actually. This has hopefully clearer arguments (the --to-namespace arg 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

Use the more natural project semantics for transfer

Makes sense to leave --id alone since there's strong precedent for it being scoped to the parent command.

You were right that switching to the project variant is much cleaner.

Perhaps the group CLI option should just be deprecated rather than renaming anything.

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.

`group transfer-project` is confusing · Issue #1529 · python-gitlab/python-gitlab · GitHub

Repository navigation

group transfer-project is confusing #1529

Description of the problem, including code/CLI snippet

Expected Behavior

Actual Behavior

Specifications

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

`group transfer-project` is confusing · Issue #1529 · python-gitlab/python-gitlab · GitHub

Repository navigation

group transfer-project is confusing #1529

Description

Description of the problem, including code/CLI snippet

Expected Behavior

Actual Behavior

Specifications

Activity

nejch commented on Jun 23, 2021

chris-peterson commented on Jun 23, 2021

nejch commented on Jun 23, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions