The right way to get latest version of a package
coocheenin opened this issue · 10 comments
Hi,
I have notice the "new" version badge. I have looked into the code. What's magic!
I mean this request. According github APIv3 docs it's the only way to get the latest release version, BUT...
In real life the most packages don't have release version. Each time a repo is tagged, a new source code bundle will automatically show up on the github "Release" page. However, these automatic "releases" will not appear via the API. It's because I wrote about magic...
I think it's more correct from a holistic point of view to get the package version from a .nimble file. What do you think about?
For example, the following code can be placed in a except section:
let dotnimble = "https://raw.githubusercontent.com/" & owner_repo_name & "/master/" & repo & ".nimble"
let r = newHttpClient().get(dotnimble)
if r.code == Http200 :
for line in splitLines(r.body) :
if line.startsWith("version"): pkg["github_latest_version"] = split(r.body, "\"")[1]Maybe I'm wrong.
[UPDATE]: Yes, partially wrong. Just now I found another function, which is involved with getting package version: proc fetch_github_versions(pkg: Pkg, owner_repo_name: string) from package_directory.nim file, not github.nim that I've mentioned before. It checks tags too!
So the right place for code typed above is here, instead pkg["github_latest_version"] = newJString "none" assignment. The latest attempt to get version. Better then none.
Note that a repository could have a different name to the main nimble file.
For example, take my repository euantorano/sever.nim where the .nimble file name is actually semver.nimble.
I believe that the eventual plan was for the nimble directory to actually be the package source, rather than a large JSON file stored on GitHub. In that cause, authors would be submitting packages and we could probably ask them to provide the path to the .nimble file on submission.
Note that .nimble files are not declarative, so extracting the version from them is not that simple. See e.g nimbles .nimble file, where the version number is imported from another module.
@euantorano Ok, but which purpose for naming like so?
(repo and package with different names)
And by the way, your repo has no releases yet.
Attempt to request curl -i https://api.github.com/repos/euantorano/semver.nim/releases/latest will raise 404.
Note that .nimble files are not declarative, so extracting the version from them is not that simple. See e.g nimbles .nimble file, where the version number is imported from another module.
Yes, right. But I suggest a solution (in example) for cases where there is no real release (only tagged automatic release). I don't see in sources extracting the tag version (only release extracting request). And sadly, we can't assume that the tags are in chronological order.
[I've updated issue.]
@coocheenin Yes, because Nimble doesn't actuallly use GitHub releases when it does version resolution itself - it always looks at the .nimble file for the package. It decides upon this file's name based upon the name of the project in the package repository JSON. THis has caused me some ehadache in the past wehn I've remembered to tag a release but not update the nimble file.
Regarding why I have a different name for the repository and the project, most of my Nim projects have a name ending in .nim to allow me to easily filter them.
@euantorano I've understand. The only open question: Does it make sense to add code, typed above, to fetch_github_versions as I've described in issue's [UPDATE] section.
Yes, it definitely needs improving in some way. I’m not sure what the best option is personally.
@euantorano Can I make a PR then? With additional check whether the target a number is (to avoid situation described by @GULPF).
I did it in async style, with additional isDigit() check: 368b89f
But i have no idea about:
ci/circleci Expected — Waiting for status to be reported
GitHub's API does not provide the latest version anymore and it was also providing it based on date rather than a semantic on version numbers.
Fixed in f2f23d2 - now we are sorting GH tags semantically.