git: allow http auth via dulwich

[abn]

This change makes use of existing repository authentication mechanisms to enable http authentication for git dependencies.

HTTP basic authentication for git repositories can now be enabled using these commands.

poetry config repositories.git-repo https://gitlhub.com/org/project.git
poetry config http-basic.git-repo username token
poetry add git+https://github.com/org/project.git

Thanks to the improvements in #5518, You can also add organisation or host level tokens by using a shorter url for the repository in config like, https://github.com or https://github.com/org. But do remember that this would apply to all clones - so project specific tokens are better. Alternatively, use poetry config --local.

This builds on top of #5428 and #5518 to enable http basic auth for vcs sources without issues like leaking credentials into the lockfile or pyproject.toml files as with previous attempts in #2169 and python-poetry/poetry-core#115.

Resolves: #2062 #2050
Closes: python-poetry/poetry-core#115

[abn]

Opted to reuse repositories here as it made sense to reuse the authenticator for this. There is a possibility that we move this into a "git" specific config section. But as an experimental feature this might be good enough.

[jkgenser]

Really excited for this commit. Forgive my ignorance of poetry's release cadence. When would this be expected in a release?

[jaklan]

@abn as nicely described in #5955, that MR doesn't fully solve the issue, because it works only when using poetry - if you want to install given package as a dependency in another, non-poetry project, you are stucked.

In general - leaking credentials are problematic, so the above feature for sure would be useful for poetry-only cases, but leaking deploy tokens with read-only permissions can be actually expected to be able to deal with private git dependencies - especially in internal projects, when you can neither: a) make the repos public b) enforce proper packaging of dependencies c) enforce usage of poetry.

Actually, taking into consideration the workaround with specifying the token manually in pyproject.toml seems to work (#2062 (comment)), the issue seems to be related to poetry add itself...

Having said that, I would be glad to hear if you see any other solutions for that issue.

[neersighted]

Generally I would avoid bundling private Git deps, and if you have to SSH keys would be the preferred way to solve this. I'm really not sure that a 'controlled' option to leak credentials into the lockfile (and thus built artifacts) is a good idea as it's incredibly likely to bite more users than it helps.

Also, the 'correct' way to solve this would be uploading your packages to a private registry -- private Git deps is not a great option for this workflow. I do think that just because something is possible as a workflow, doesn't mean it's necessarily a good one. Maybe beefing up our docs to suggest against using Git deps for private packages would be helpful.

Regardless, let's take discussion back to #5955 as this is not a great forum/place for a feature request.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.