dvdotsenko / git_http_backend.py

Port of git's "Smart HTTP" (git-http-backend) server component to Python WSGI interface.
git_http_backend_python_wsgi
GNU Lesser General Public License v2.1
72 stars 15 forks source link

Installation guide and examples are missing #2

Closed vdboor closed 14 years ago

vdboor commented 14 years ago

Hi,

I'd love to use this app, but have no idea how to install it. (I do have some experience with WSGI apps, but even pointers to what is the main function are missing).

I'd love to see this app in use!

dvdotsenko commented 14 years ago

Hi.

Good point. I did not populate the read me for git_http_backend.py yet. Will do so this weekend.

Daniel.

dvdotsenko commented 14 years ago

Committed to a basic "examples" structure and provided the first deployment example.

Will be adding more documentation as other deployment scenarios are confirmed to be working.

vdboor commented 14 years ago

Thanks!

One thing I didn't quite get yes, does this run as separate server? Or can I somehow to a <Location /git/> rule in apache, to redirect all URL's to your script?

dvdotsenko commented 14 years ago

The server is "Python WSGI servelet" which means it runs against all WSGI compatible servers.This should include the mod_wsgi under apache. However, I did not test Apache + mod_wsgi yet, and, consequently, did NOT provide and example for that yet. I will in a week or so.

The git_http_backend.py was designed for specific simple deployment scenarios. Primary mission is to fill a "simple" GIt server need on intrAnet (workgroup), where security is provided by outside firewall.

The first provided example - command-line deployment method - runs against a WSGI server built into Python runtime itself. Hence, it's very easy to run it, but it cannot be a service without making the script itself a service. There was intentionally no user-rights management built into the "command-line" deployment mode. This is the most basic deployment scenario - when you need an ad-hoc git server that you would serve temporarily (Use remove desktop / ssh into a server, run the git_http_backend.py in command-line mode and close the remote session when you don't need the server any more.)

I do intend to wire up user/rights management next. That feature will heavily rely on the hosting server (apache, MS IIS) for user authentication. Because of my specific corporate requirements, my first target is MS Windows IIS, with ActiveDirectory-based user authentication and rights management based on "All or nothing" access where "authed" user can write and read to any repo.. Apache will come next with the same "rights" logic.

Last will come "layered" rights management, where users are allowed Git functions based on ACL-like rules, which would allow group ownerships of repos, control over who can "auto-create repo on Push" and read / write granularity. "rights" Storage requires some sort of DB storage backend that is non-standard (cannot be attached easily to LDAP / AD) and I don't want to bog down with that just yet.

Depending on where on the "user rights management complexity" scale you fall, you will either have to wait a while (for code to be written and examples to be provided), or very little (just for examples and very minimal code to be written).

vdboor commented 14 years ago

Thanks for your info, I'll see when I can use it!

Would you consider using Django for the whole management app?

dvdotsenko commented 14 years ago

Hi.

Re: Would you consider using Django for the whole management app?

I am not particularly against a Django front end.

I have personal inclination to use something else but Django because it ties the application to a particular DB schema. It practices "Active record" pattern, which means, you change your object model, your DB table changes. I prefer frameworks that rely on higher DB abstraction, like Pylons + SQLAlchemy. However, it's my personal thing and I never really dictate it to anyone.

The repo file-browsing over a server-based web UI is actually a difficult thing with Git. To view files, the UI will effectively need to do a complete fresh checkout of a particular version, throw that into memory and present it like a folder. You cannot pluck a single file out if you use git executable. A much easier job is to implement the viewer that just shows repos available. If someone wants to see a list of repos, that's an extremely easy thing to implement as a web-based interface. And could be a good start.

However, you don't need an MVC system like Django for that. A simple single-page, AJAX-enabled UI would be perfect. My immediate focus is on the "simple repo lister implemented and I would settle for a simple AJAX-enabled single-pager.

However, I would definitely help you if you take up on the task with whatever the tools you prefer.