forkability
forkability copied to clipboard
basicallydan
Check for version tags
A good indicator of a well maintained open source project is the existence of Tags (or Releases). Some systems rely on existence of these (such as Bower), and while others use a separate system (Node) it can be incredibly useful for developers looking at a project to see tags for each available release.
IMO there are two ways of validating tags: generally, and language based.
Generally
Checking for the existence of any tags in the repo (e.g. asserting at the length of the Array in https://api.github.com/repos/basicallydan/forkability/tags is > 0) demonstrates at least some level of commitment from the developers to release stable versions.
Language Based
Looking at the choice of package manager, and discovering releases on that package manager, and tallying it up to the tags on github, for example http://registry.npmjs.org/forkability has 5 tags as of writing - 0.5.1, 0.6.0, 0.7.0, 0.8.0 and 0.8.1. We should expect https://api.github.com/repos/basicallydan/forkability/tags to have the same information - although the version tags typically start with 'v' which may need to be accounted for.
Hey @keithamus thanks for the input!
Bower relies on the use of tags? Interesting.
I really like this idea, but I'm not entirely sure what the level of tag use is like. Given that it's required for projects which use Bower then I can certainly see the use of it there. But I must admit I'm slightly afraid of incurring the wrath of people who aren't too fond of tags. Do most good repos use tags in some way or another.
At the very least, checking for length > 0 I think might be wise.
As far as comparing npm/git for node projects, then, well... I think that could work quite well.
Hey @keithamus, at a conference today I chatted with a man who described to me a use case for tags in open-source projects. To paraphrase:
If I'm using an OS library which is broken, I want to go and find the source at the version I'm using. With tags I can do that - without them, the source on GitHub just isn't a reliable representation of the broken source code.
So I'm convinced now! I'll make tags a requirement!
In 0.10.0, tags are being checked, but only the existence of them. I want to implement this for nodeJS tag parity before closing this issue :)
pong
@M-Zuber This is over a year old! Okay, so I guess the thing to do here is to check that for NodeJS projects, the tags are in NPM and in the repo. Agreed?
Sounds right, but we first have to check that the project is in npm. We treat every js project as NodeJs project. But that does not say anything about it being on npm.
Ah true. Probably straightforward though, just check if the URL is 404 or not. Or maybe NPM has an api for this.
And then if the project is not on NPM, it doesn't get checked for this - just git tags. On 16 Nov 2015 18:51, "Mordechai Zuber" [email protected] wrote:
Sounds right, but we first have to check that the project is in npm. We treat every js project as NodeJs project. But that does not say anything about it being on npm.
— Reply to this email directly or view it on GitHub https://github.com/basicallydan/forkability/issues/30#issuecomment-157007214 .
@basicallydan I might be able to help out with the data for this issue, I've been working on an API for https://libraries.io which will let you get version info about a given npm module, you can also find all the npm modules that reference a particular github repo as the source code for that module.
Docs here: https://libraries.io/api, let me know if there's some other data you'd like that's not available and I'll see if I can add it
Thank you for taking the time to look at this.
What do we gain by calling your api as opposed to npm's directly?
Other than dependencies for the repo currently being linted :wink:
Some other points:
- how do we hide apikey? we can't leave it open due to the second point:
- how do we deal with the rate limit? @basicallydan is 60 rpm good enough? I would hope that yes
- Assumption is that we just hard code the url somewhere? or will there be a package at some point?
Final point:
Is there a way we can get this set up in time for December? Preferably so that it will be first-timer-only friendly?
@andrew That is helpful, thanks - but we really only need the version tags at the mo which we can get from NPM directly. Thank you though, very good of you to point this out :smile:
Given that Forkability is a browser- and Node-compatible tool it probably would be easier just to use the NPM registry.
I wonder if the NPM registry has a rate limit. @andrew do you know?
Ah I didn't realise it was only for node projects, there's lots of useful tips for non-node projects here too.
As far as I know there's no rate limit on the npm api, or at least I haven't hit one yet
The general project is not only for node projects. Just the current focus for linting tags.
If the change discussed in #61 for the lint rules rewrite goes forward, then we can easily add checks for other package managers.
Using the libraries.io api might be a good idea because it abstracts away all of the package management stuff that you'd otherwise have to do. I guess the only problem with using it is the API key issue.
NPM's API is pretty easy to use and very forgiving, not sure about other package managers.
For sure once we get up to checking against multiple package managers it will be a blessing as its one api to code against. Until then we shall have to see
@andrew @keithamus @M-Zuber I see now, very good point... I think that went over my head at first.
If we can keep it language agnostic then yes, my whole concern mentioned in #61 would be solved somewhat.
@andrew Does libraries completely normalise the output for versions regardless of platform?
I believe the changes being discussed in #61 are still relevant irregardless of the api being spoken to. Will try to clarify feedback on that, there
I've not documented it but you don't actually have to pass an API key for the libraries api, the rate limit will just be based on your IP address.
@basicallydan yeah Libraries stores all libraries from every package manager in the same format, so the api is identical for everyone, some fields may have no value if the package manager doesn't support that feature.
For package managers that don't have a real repository like Go and Bower, Libraries fallback to GitHub tags for version numbers too, so you always end up with basically the same data, no package manager is a unique snowflake ❄️
For package managers that don't have a real repository like Go and Bower
@andrew Frickin' Bower. Always ruining everything.
Okay, cool. That sounds great actually. I doubt any user of Forkability will be doing any heavy requesting over the limit, and when we get the library to work as a web service we can use an API key on the backend. Schweet. Thanks dude.