copier icon indicating copy to clipboard operation
copier copied to clipboard

feat(settings): custom shortcuts

Open noirbizarre opened this issue 1 year ago • 3 comments

It makes the prefixes (currently gh: and gl:) customizable using user settings, allowing to:

  • add your own (remote and local)
  • override the existing ones (especially to force ssh access on private repositories)
  • benefit from specific GitHub and GitLab behavior on alternative, private or corporate instances

It moves URL normalization into the settings to benefit from custom shortcuts.

Some decisions are required on the vcs.get_repo() behavior: it currently only assumes https://gitlab and https://github are http git repositories, unless prefixed with git+. However, non git remotes are not supported, so I wonder if it would be simpler to consider all https:// as git repositories (it would fail if this is not the case, whatever this method returns)

noirbizarre avatar Jan 20 '25 01:01 noirbizarre

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 97.93%. Comparing base (1dabe8e) to head (2881060).

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1941      +/-   ##
==========================================
- Coverage   97.93%   97.93%   -0.01%     
==========================================
  Files          53       53              
  Lines        5677     5705      +28     
==========================================
+ Hits         5560     5587      +27     
- Misses        117      118       +1     
Flag Coverage Δ
unittests 97.93% <100.00%> (-0.01%) :arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

codecov[bot] avatar Jan 20 '25 01:01 codecov[bot]

So, back to this one ! As written in the PR description 👆🏼, given this discussion, I'd like to know the direction I should give to this PR:

  • should it assume that all http URLs are git repositories, given this is the only supported case? (This what has been done in the test of this PR)
  • about URL normalization, which this PR has mostly move to settings, what should be done ?

This will mostly have impact on get_repo() and GIT_PREFIX

I will adjust this PR accordingly, but I need some decision and directions.

noirbizarre avatar Mar 02 '25 17:03 noirbizarre

  • should it assume that all http URLs are git repositories, given this is the only supported case? (This what has been done in the test of this PR)
  • about URL normalization, which this PR has mostly move to settings, what should be done ?

IMO, it would be consistent to treat URLs identically when passed as a source to copier {copy,recopy} and when listed as trusted URLs in user settings. If you use the same logic as the Template.url_expanded property, then all HTTP and SSH URLs are treated as Git URLs, and if they can't be parsed using get_repo(), then the original URL is used as a fallback for, e.g., local paths. Off the top of my head, I can't think of a security problem when also normalizing the trusted URLs like this. And not normalizing trusted URLs, i.e. requiring a user to provide a normalized URL in the list of trusted URLs, feels brittle and unexpected by users.

sisp avatar Mar 03 '25 14:03 sisp