IGitt

[sils]

Hey, you're interfacing with different providers here and we're doing that as well, it kinda sucks that we all have to find a solution for that: maybe it would make sense to collaborate on https://gitlab.com/gitmate/IGitt ?

[guyzmo]

Hi @sils,

the main goal of git-repo is to offer a unified CLI API for all the git services. I have already implementations working for github, gitlab, gogs/gitea (to the extent of its API support) and bitbucket. The design of git-repo, though, has been to have a decent decoupling of the service side from the CLI side.

Current goal of git-repo v1 is to figure out the best CLI API unification to offer for each feature offered by git services (with the right balance between exposing the common demonitor and adapting to extra features).

Because the goal of git-repo is not to reinvent the wheel, and because I don't want to take the extra-workload that comes with it, I'm not implementing direct API calls to the services' API. I'm always using an intermediate library (github3.py, python-gitlab, pygogs, python-bitbucket) that does the job for the tool. I also have implemented regression testing (which does not mean it's perfect).

Looking at your library, it looks like it's pretty young (only supporting GitHub at the moment), designed so it does not use external libraries (i.e. you're implementing yourself the services API), and has doctests testing (which is very limitating).

For git-repo 2.0 I'm definitely thinking on externalizing the service as a lib.

My current thinking is on building it as a dependency tree, a module exposing the git-service class (and eventually split it as several feature-oriented class in the fashion you're doing it in IGitt) as abstract (with all methods raising NotImplemented), then each implementation requiring that implementing the common class to offer the features to a tool using it.

Then each tool like git-repo (and eventually yours could be as well) could work the same way, and adding/removing support for a service would be a matter of pip install it.

Whether it's a good or a bad design is up for discussion, I'm far from there yet, I don't see 2.0 anytime soon. You're welcome to come discuss all that on IRC, #git-repo on irc.freenode.org.

Currently the plan: full bitbucket support (next release), fix all issues, make sure git-repo works bug-free and with the best UX across all services and systems, rewrite github support for github3.py upcoming v1.0.0, implement some extra features — like issues and ssh keys management, split the repo.py code across submodules (to split the help in multiple smaller help commands).

[sils]

Thanks for the response! It seems like we have the same goal and you're about to build something like IGitt on long term, I'd like to join you in that effort because we need the same and I don't necessarily need to keep IGitt, am happy to drop it if some other approach seems more feasible.

CCing @nkprince007 here who is doing some related stuff where one of the next steps would be putting some effort into IGitt or building an alternative.

About not using external libraries: I tried that and don't remember why I dropped it. Maybe I was just too impatient to wait on upstream implementing/reviewing something and dropped it for the more fun approach of writing GitHub support myself (fun is actually a pretty good argument for reinventing the wheel IMO ;)). Happy to drop that as it gets serious, the more I think about it the more I think we should.

Using doctests is just because I'm lazy and the library is in an early stage. The testsuite isn't as good as I'd love but it's doing it's job well and I'm planning to introduce pytest as soon as needed so we have doc+unittests. (I'm not a fan of misusing doctests like I did there ;))

[guyzmo]

well, I'd be happy to keep the discussion on, but to smoothen and figure out a plan, we need to gather and have a chat:

→ irc.freenode.org #git-repo

[jayvdb]

Two important missing parts of git-repo (which are in IGitt) are

• issue support , which is add support of issues #104 .
• commit build status, which is sort of query build status for a repo/branch/pr #134

The class structure of IGitt is also a little more developed, but mostly because of the above two features.

We hang out in https://gitter.im/GitMateIO/open and https://gitter.im/coala/coala, but ive also joined on your irc channel using matrix.org to help keep the conversation flowing.

[guyzmo]

after a while not having time to work on the project, and giing it some time to think about it, I believe that the git-repo source code is not yet ready for targeting two projects.

on one hand, having more hands on deck to work on the library would be great and might help develop faster, but on the other, having to mitigate design decisions for client vs service use cases is likely to slow down reaching my goals regarding git-repo v1. Also, even though I think the frontend (CLI) and the backend (service abstraction) are fairly loosely coupled, I noticed that the Repository and the backend are a bit too tightly coupled to my taste, and for generalising the backend yet.

That being said, I'm now near completion of my targets regarding git-repo v1, all that's missing is issue and ssh key support, and a few extra minor stuff (like build status reporting). And git-repo v2 means refactoring both parts of the tool (the CLI frontend as well as the services library that might become the common part), so I believe that would be then a good time to merge both projects.

Meanwhile, what can we do? First, keep communication channels open, yesterday I joined your coala gitter, as you joined irc://irc.freenode.org/git-repo on March 20th. Then, keep on building our own libs as separate first versions, so that we can know better our use cases and needs. Because I've had a head start and I already support 6 backends, maybe you could just focus on a couple of services, but really think through how you want your API to look like.

Then as I reach feature completion on v1 and start with v2, we can compare both projects side by side, and look at what's common and what's different, and extract from my code the common parts, and build an abstraction that covers the differences in an intelligent way for both gitmate and git-repo.