dub-registry icon indicating copy to clipboard operation
dub-registry copied to clipboard

Add support for more git hosts

Open SuperDoxin opened this issue 8 years ago • 14 comments

currently only github and bitbucket are supported. I would love to see at least gitlab.com supported too, but ideally any git url ought to work.

SuperDoxin avatar Jul 31 '15 01:07 SuperDoxin

Supporting this as well, seems like it would be natural to allow any given git remote.

edit: right, so it seems like the GitLab support is already in the repo, but have you given allowing arbitrary git repositories?

profan avatar Jul 31 '15 02:07 profan

The problem with arbitrary git URLs is mainly the download link. It would require downloading, extracting, zipping and storing all of such packages locally on the registry server. Currently this wouldn't be an issue, but if we ever grow to the numbers of packages that the most popular package systems have today, it will require an upgrade of the hardware infrastructure. Another potential issue is that every git repository requires its own server connection, while the HTTP hoster protocols can reuse the same connection for many consecutive requests. So this would create a lot of overhead for both, the registry and the hoster.

So, this is certainly doable, but doesn't scale well enough for the current server infrastructure.

GitLab support is basically there, but so far I've only tested it with a local GitLab instance. I'll switch that live probably in about one or two weeks.

s-ludwig avatar Jul 31 '15 12:07 s-ludwig

so why isn't the git protocol being used here? seems to me that the dub client could just git clone whatever it needs instead of the server having to hand it a zipfile.

SuperDoxin avatar Jul 31 '15 15:07 SuperDoxin

Using the git protocol would mean either that the server would have to mirror all repositories, while it now only has to store the meta data, or the client would also have to use either libgit or the git command line client, both of which is problematic in one way or another. This would also mean that git gets special treatment - but we currently also support HG repositories on Bitbucket for example, because everything works using HTTP.

s-ludwig avatar Sep 14 '15 18:09 s-ludwig

I too would love to see GitLab support.

sigod avatar Feb 29 '16 09:02 sigod

I've added a branch where the code I once wrote for GitLab is integrated: https://github.com/D-Programming-Language/dub-registry/tree/gitlab-support

Would be good if someone could test this and provide patches if necessary. I'm currently lacking the resources to finish this and we have internally switched to Gogs now, so when I get the time I will concentrate on that instead.

s-ludwig avatar Feb 29 '16 09:02 s-ludwig

I'm currently lacking the resources to finish this and we have internally switched to Gogs now, so when I get the time I will concentrate on that instead.

Very interesting service. Are there any major hosting for it? I don't see how it can be supported for user hosted packages.

sigod avatar Mar 03 '16 01:03 sigod

Gogs would indeed just be for private/internal hosting, I don't know of any public service, although I haven't searched for it either. I want to set up a local dub-registry, so that building projects just works, without having to manually clone all dependencies.

s-ludwig avatar Mar 03 '16 06:03 s-ludwig

I'd really love to see gitlab support :) Would it be possible to merge that yet?

BlackEdder avatar Sep 26 '16 10:09 BlackEdder

Using the git protocol would mean either that the server would have to mirror all repositories, while it now only has to store the meta data, or the client would also have to use either libgit or the git command line client, both of which is problematic in one way or another. This would also mean that git gets special treatment - but we currently also support HG repositories on Bitbucket for example, because everything works using HTTP.

If you choose to support git through calling the command line, then it should be pretty trivial to do the same for the hg client? Of course this does require for those tools to be installed, but this is quite common at the moment. The slight inconvenience for requiring git to be installed, seems to be a good trade off for getting support for any git/hg repository.

BlackEdder avatar Sep 27 '16 08:09 BlackEdder

Any progress on this? I'd really prefer using gitlab over github.

BlackEdder avatar Jan 06 '17 09:01 BlackEdder

I would like to use gitlab with the registry too :)

gedaiu avatar Apr 03 '17 13:04 gedaiu

Is there a way you could add support of granting per-user basis a way to add their own git server to the list but only visible to them? For example I've moved my project off GitHub due to the recent Microsoft acquisition, over to my own server. (using go gogs)

LunaTheFoxgirl avatar Jun 07 '18 05:06 LunaTheFoxgirl

I was plinking around with this a bit. The best I think you can get:

1: You don't need to check out anything if you're just checking if things are up-to-date. You can just use:

mkdir tmp
cd tmp
git init
git remote add https://some-private-repo.mysite.com/path/to/repo.git
git ls-remote --tags origin

2: you can download and work with only the affected revisions.

git fetch --depth=1 --prune origin $revisionHash
git reset --hard $revisionHash

For vibe.d, this incurs 6.17MB of network bandwidth instead of 19.88. Not awesome savings, but still savings.

3: you can save a bit of disk space with git's sparse checkout option.

git config core.sparseCheckout true
echo > .git/info/sparse-checkout <<ENDL
dub.sdl
dub.json
README.md
README.rst
README.txt
README
ENDL

Unfortunately, sparseCheckout doesn't affect the amount of storage used in .git or the amount of network bandwidth used.

Using the git API directly would let you avoid disk space, but not network bandwidth. I don't know how much bandwidth costs for the dub registry server, so I don't know whether this would be acceptable.

dhasenan avatar Jan 04 '19 01:01 dhasenan