neume-network / core

A socially-scalable music NFT indexer.
https://neume.network
GNU General Public License v3.0
26 stars 11 forks source link

Consider using the HTTPS URL rather than SSH URL for submodules #59

Closed almndbtr closed 2 years ago

almndbtr commented 2 years ago

Summary

Currently, the lone submodule points to the SSH URL:

https://github.com/neume-network/core/blob/8afe75b6ce1c3ff3ba0096f4a6b8acfa78e81dab/.gitmodules#L3

For new users (like me!), it's possible that we don't have SSH keys set up by default with Git. In that case, Git will produce this funny error:

git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
fatal: clone of 'git@github.com:neume-network/strategies.git' into submodule path '/workspaces/core/src/strategies' failed
Failed to clone 'src/strategies'. Retry scheduled
Cloning into '/workspaces/core/src/strategies'...
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

My gut tells me that HTTPS on the other hand should "just work" for most configurations without any additional setup (happy to be corrected if that's actually false 😂).

Suggested change

-      url = git@github.com:neume-network/strategies.git
+      url = https://github.com/neume-network/strategies.git

Happy to cut a PR for this, if there are no objections ✌️

TimDaub commented 2 years ago

This is related to #56. The problem is that I assume most people use SSH when handling git remotes so after the initial installation, they'd have to replace the https remote with SSL.

If possible, I'd like to find a balance here. E.g. in #56 the solution is to choose a HTTPS remote for GitHub Actions CI. But then e.g. I want neume-network/strategies to be installed with SSH.

@almndbtr: Do you usually also access GitHub using HTTPS?

almndbtr commented 2 years ago

Do you usually also access GitHub using HTTPS?

@TimDaub - Lately, yes. I've been using GitHub Codespaces' happy defaults and it's gotten me through most of my day-to-day development work without having to set up an SSH key.

I realize that this may not be others' typical working environment 😉 -- all that to say, I'm up to find a balance with you.

But then e.g. I want neume-network/strategies to be installed with SSH.

Exercising curiosity: is there a specific set of advantages when installing neume-network/strategies over SSH versus HTTPS, even with it being a public repo? I want to make sure I'm not missing anything before I make any suggestions. 💭

TimDaub commented 2 years ago

Exercising curiosity: is there a specific set of advantages when installing neume-network/strategies over SSH versus HTTPS, even with it being a public repo?

Anecdotally, I'd say that developers are using SSH over HTTPS simply because authorization via keys is more convenient once set up. But anyways, unless you find a strong resource suggesting otherwise, I'd either argue for making the definition protocol-agnostic somehow or by defaulting to SSH.

almndbtr commented 2 years ago

Anecdotally, I'd say that developers are using SSH over HTTPS simply because authorization via keys is more convenient once set up.

👍 , putting myself in those shoes, having had it set up when I used to work on my actual machine to develop.

But anyways, unless you find a strong resource suggesting otherwise, I'd either argue for making the definition protocol-agnostic somehow or by defaulting to SSH.

I hear that perspective -- the only thing that comes to mind for why I'd "push" for HTTPS URL is new developer contributor velocity. Putting myself in your shoes as a maintainer, I would want new contributors to have the least amount of friction when embarking on the path to development:

Keeping the SSH URL in the Git Submodules configuration adds one more step for developers who don't already have those keys set up. It would help them in the "long run" (convenience, to your point) for this project and others, but may detract newer folks from wanting to continue on after going through that process.

If that one step is a strong enough case to change your mind, I can cut a PR to update that URL. Otherwise, I'm happy to yield to your preference as this project's maintainer (as I'm just a curious contributor 😉 ) and follow-up with a new suggestion. For newcomers, I think it would be helpful to add a new note in the docs.

Specifically, because this project relies on Git submodules, they will either need to one of the following before running npm i:

TimDaub commented 2 years ago

closing this in favor of #56