dlang
The number of tags per package shouldn't be limited
[Original title: Selections of git tags could be different]
Problem
Someone came on IRC after trying to build https://github.com/kiith-sa/d-gamedev-intro which was last updated one year ago.
This project use gfm version 1.2.5, but didn't build anymore.
Root package Asteroids contains reference to invalid package gfm:sdl2 1.2.5
I advised to use the latest 1.x.y tag since this project should have used ~> in the first place.
But it appears none of the 1.x.y tags are available in the DUB registry.
I know I make plenty of git tags, but this is for users: without a git tag they can't use the patched library.
It seems that the DUB registry scans up to 30 tags git tags in addition of ~master.
While I do not advise to scan every tags (most are uninteresting after a while indeed), I would suggest to scan each latest major version tags to minimize breaking applications.
It was not that easy to find the problem, since DUB output is:
Root package Asteroids contains reference to invalid package gfm:sdl2 1.2.5
A message like Are you sure this tag is listed in the DUB registry? would have helped this user.
<joshsyn> Understable now though why the error happens at least. However I am in favor and would like to suggest to add in more helpful messages to the compilers and other toolset that belongs under D
I didn't know that GitHub had this limitation and was about to say that it hard to do something about it, but then fortunately discovered this: https://developer.github.com/v3/#pagination
Still requires some work to resolve properly, but is doable, and there is a quick workaround by setting ?per_page=100.
As for the error message, I know that they are far from being ideal, but improving them requires a rewrite of the dependency resolver, which will happen at some point, but it's not something quick.
Is such a number of tags a problem for the DUB registry? Would it make scanning longer?
No, the problem is just that the pagination requires additional work, especially because the pagination information is passed in the HTTP header, which is currently not cached (and caching is basically required for all requests to the GitHub API).
Ah no, let's better keep this open until it's fully fixed. My proposal is to not use the header information, but to continue looking for another page as long as the maximum amount of tags is returned form a single page. Will be as efficient in at least 99% of the cases and doesn't require changes to the cache.