Include a depth of followers option

[needmorecowbell]

There is a getFollowers() function already in giggity. I would like to add the ability to include followers, then followers of followers, and so on to a depth of x. This would be added as a separate nested dictionary added as a key to the user level called followers.

In this way we should be able to find mutual followers to a certain organization or user.

[adi928]

Hey there,

I was able to come up with something for this enhancement. I have made a commit here: https://github.com/adi928/giggity/commit/64e24e1c7ec1a3d7f83f35e5f10d23da0a314390

[needmorecowbell]

Thank you! This is the data we need, but I'd like to add a way to pipe these followers into the hierarchical data structure so it would look something like this. The keys to mention are followers and repos -- I would like to handle followers how repos is handled. Check getRepos() , it's the same thing just for followers. instead of repos.

 "users": {
        "usernameOfOrgMember": {
            "avatar_url": "https://....=4",
            "events_url": "https:/....y}",
            "followers": {
                    "followerOfOrgMember": {" ... "},
                    "followerOfOrgMember2": {".."},
            },
            "followers_url": "https:/....wers",
            "following_url": "https:...._user}",
            "gists_url": "https:/.....st_id}",
            "gravatar_id": "",
            "html_url": "htt...",
            "id": 111,
            "login": "B...n",
            "node_id": "M....Mx",
            "organizations_url": "https://api.gith...rgs",
            "received_events_url": "https://....eived_events",
            "repos": {
                "repo1": {
                    "created_at": "20...4Z",
                    "description": "......c\udfc5",
                    "fork": false,
                    "name": "8...er",
                    "updated_at": "2018-12-04T04:50:09Z",
                    "url": "https...aker"
                },
                "repo2": {
                    "created_at": "20...Z",
                    "description": "Per...tion",
                    "fork": false,
                    "name": "B...o",
                    "updated_at": "2...0Z",
                    "url": "ht...ub.io"
                },
            "repos_url": "https://api.git...epos",
            "site_admin": false,
            "starred_url": "https://api...wner}{/repo}",
            "subscriptions_url": "https://api.github.com...ubscriptions",
            "type": "User",
            "url": "https://api.github.com..."
        },

Eventually it would be nice to add an optional integer parameter to -f, ie: giggity.py -a -f 2 -o github -O github.json to get the followers of followers (3 = followers of followers of followers) of each member in the github organization. That's not necessary right now though, it shouldn't be hard to add once the follower key is added correctly, since it will still use the same getFollowers function, just for each follower however many times.

[needmorecowbell]

Latest commit now has follower flag. I'm going to keep this issue open because depth is still not taken care of, but because it now would be easily possible to handle a depth-focused search using the api I don't see it as such a necessity.

https://github.com/needmorecowbell/giggity/commit/7ecf7d1502ef7d960cd5028639185fbd3c156a98

[adi928]

I took the above commit and added depth parameter and used depth in getting levels of followers. But it becomes really slow when people have like 900+ followers. Any workaround for that or we have to go with it?

The commit which has necessary changes: https://github.com/adi928/giggity/commit/8a8a3749145f21c23ecd6e62da28df7f6e917c6e

I can create a PR if everything is fine with the code.

[needmorecowbell]

That looks great, thanks! Yeah if you could make a PR that'd be awesome. The requests could be made concurrently but I'm worried about it getting limited by github's api terms of use. Using two or three threads instead of one might be enough to avoid any abuse of service and still give significant speed boost, but at 900 followers using the depth function, the requests limit is going to get filled up pretty quickly. Really, using the depth function to a degree larger than 3 could lead to some really large results.

Instead, I think maybe it should just be handled by a ratelimited mode, where it pings every 15 mins to see if it can start making requests again after finding out that it's been ratelimited. See issue here: https://github.com/needmorecowbell/giggity/issues/8