"Easily" switch between HTTPS and SSH

[itavero]

I'm currently looking into deploying CPM.cmake within our organization.
The "shorthand" URIs look convenient, but I think it's a downside that they always resolve to an HTTPS link.

For public repositories, this is probably fine, as no authentication is needed.
For private repositories, we tend to stick to SSH keys for authentication (at least on our development machines; the CI pipeline is probably a different story).

I think, depending on the environment, you'd either use SSH for all of your GitLab repositories (or GitHub, or BitBucket, ...) or you'd want to stick with HTTPS.

If #333 would be merged and provide the relative URI mechanism in line with my expectations, we can probably use that to work around the different URI schemes on different environments.

Otherwise, I think it makes sense to be able to influence the URI scheme from an (environment) variable, something like:

• CPM_URI_SCHEME_GL, for GitLab
• CPM_URI_SCHEME_GH, for GitHub
• CPM_URI_SCHEME_BB, for BitBucket

These variables could either be unset, or set to ssh or https.

Based on this the CPM_ARGS_GIT_REPOSITORY can be set accordingly for these different providers in CPM.cmake.

How do you feel about such an addition?

[iboB]

The suggested global config options seem to me like a recipe for pain when testing and dealing with conflicting settings from the tree of dependencies.

I think a better solution would be to just add more shorthand schemes like ghs, bbs, gls (and I'm not sure whether I'm in favor of even that)

The shorthand syntax works with full uris as well. You could easily use: CPMAddPackage("[email protected]:XXX/[email protected]") adding a few more bytes. Or, if you prefer:

set(ghs "[email protected]")
# ...
CPMAddPackage("${ghs}:XXX/[email protected]")

[itavero]

The thing is that which scheme to use does not depend on the project, but rather on the environment you are building on.
Several CI pipeline systems I know of tend to use HTTPS, but our developers tend to use SSH locally.
So, without changing what's in my SCM for a project, I want to make the switch.

Additional shorthand schemes would not really help for that.
Of course I can roll my own solution for this and distribute that throughout the organization, but that seems a bit counter-intuitive.

Also, can you elaborate on "dealing with conflicting settings from the tree of dependencies"?
Not sure how you can have conflicting settings, if it's one "global" option you configure depending on the environment.

[TheLartians]

Hey, thanks for the issue! As this seems to be a machine dependent configuration option, have you looked into simply using the git config for specifying how you'd like to pull and authenticate certain repositories on each machine? It can be used to easily switch between ssh and https on a per repo or host basis. This has the advantage of working consistently with different package managers (e.g. pip for python) throughout the system.

Supporting CI with this approach is also straightforward as illustrated in our README.

Using git config also fixes unexpected issues like cache misses compared to changing the URL using a variable, as seen in #350.

[iboB]

@itavero overriding arguments via a configuration setting always leads to edge cases which hard to identify and hard to test. I'm not sure how this particular setting might affect things, but my gut tells me that it's a bad idea. A (somewhat contrived) is that on a system with several instances of package X which requires package Y and makes use of a global cache, in certain cases CPMAddPackage("gh:XXX/YYY.git") will lead to one download directory (based on https) and in others to another (based on ssh). Moreover since there is no version specified, these will potentially have different contents based on when the package is downloaded. If this is a monorepo with different build flavors this may introduce hard to detect problems if one expects all instances of CPMAddPackage to lead to the same source. Note that this is achievable even now because of other settings that can be enforced from the outside world.

Still, it's the examples that I can't think of that make me weary of this proposal.

Your suggestion only affects the shorthand syntax. Using the full syntax of CPMAddPackage would remain unaffected, and this can again lead to strange behavior if one switches from one to the other.

I agree that additional schemes are not the best idea and I'm definitely not pushing for them.

Using a custom variable for prefixing uris can also work and would even support relative paths (though in this case all affected uris must be touched by the team).

Using .gitconfig as @TheLartians proposed seems like the best of all worlds, no?

I personally am trying to think of a good way to handle package uris, which will support relative paths, redirection, and perhaps most importantly potential future CPM repos (allowing something in the lines of CPMAddPackage([email protected])). I don't have anything good so far.

[itavero]

You both have valid points. I always forget about the rewrite option. I'll see if I can easily deploy a Group Policy in our domain to add these automatically for out engineers.

With regards to the package URIs: I think you'd need some kind of registry for that.
I believe I once came across a similar idea for CMake, I think it was this repository: https://github.com/vector-of-bool/CMakeCM

Anyway, I'll close this issue. Thanks for the feedback! 👍