Add ssh based modules installation

[sakulstra]

Hello, opening this discussion as I feel very strongly about this topic.

#924
#2407

The reasons for me to dislike the forced https:

• setting up a custom token is cumbersome
• it's pain in ci
• typing passwords is annoying as well
• developers already using ssh in my experience is the norm. For the few devs i faced not already using ssh, it has never been a problem to convince them using it. There's good docs on github to set it up.

I think not giving users a choice is the wrong call.

[onbjerg]

I'm mostly worried that new developers that start out using Forge would be confused if the libraries they use start using SSH, and this leading to an increased support burden for us. It's not really perfect either way: if people use HTTPS submodules, SSH users will complain (have to enter password), if people use SSH, HTTPS users will complain (have to create key). Unsure if there's a generic way to allow either.

It's not necessarily the case that using SSH submodules in your project won't affect others since submodules are pulled recursively, so a library that uses SSH submodules would force everyone further down to use SSH afaik. Same for HTTPS. So users don't really have a choice either way: either we force people to use one of them, or other developers will inadvertently do it

[sakulstra]

I'm mostly worried that new developers that start out using Forge would be confused if the libraries they use start using SSH, and this leading to an increased support burden for us.

From personal experience it's the other way around 😅 - never before a tool suggested to do a config setup to use authenticated https.

It's not necessarily the case that using SSH submodules in your project won't affect others since submodules are pulled recursively, so a library that uses SSH submodules would force everyone further down to use SSH afaik. Same for HTTPS. So users don't really have a choice either way: either we force people to use one of them, or other developers will inadvertently do it

While this is true it's very unlikely i'd say. I would assume most ppl use ssh for private modules and only ppl who rely on these private modules would ever be in a situation to have a recursive dependency on them. Pretty sure this won't randomly affect lot's of people. Non private https won't break anything for ssh users.

Unsure if there's a generic way to allow either.

Wouldn't it be a reasonable compromise solution to give the user the choice when installing & perhaps enhance the error?
Not very experienced with rust but as it just uses git submodules under the hood, i guess it shouldn't be too hard to catch submodule related error and enhance it with a 1 sentence explainer and link to ssh/https setup guide?

[onbjerg]

Unfortunately due to the recursive nature of submodules it's not enough to just replace one URL somewhere - if you have a submodule that then uses another submodule, you'd need to recursively change it which would also lead to dirty submodules. We wouldn't know if the submodule is dirty because the user changed anything of signifiance, so forge update would break.

We can change the behavior if you want, but I'm still fairly certain we'll end up having to provide git support

[sakulstra]

We can change the behavior if you want, but I'm still fairly certain we'll end up having to provide git support

Would love the behavior to change and work on a pr if there's a chance of this being merged.

Every new person cloning a repo is facing the same issue and while setting up a token on github works it's quite annoying.

[sendra]

Was recently trying to use some private repositories in a forge project I am working on, and as installing via ssh does not work, it is a pain.

As the repository i want to install its private i would have to install via user and password, but authenticating with password has been deprecated for a year now.
So the only way, is to use a PAT (Personal Access Token), which in my opinion is way more dangerous and complicated than being able to install via ssh.