Re: Obtaining content from Git

On Mon, Nov 24, 2014 at 7:43 PM, martin f krafft <madduck@madduck.net> wrote:

also sprach Russell Keith-Magee <russell@keith-magee.com> [2014-11-24 11:38 +0100]:
> Perhaps I wasn't clear.

No, you were. I am just pushing back a little bit because I come
from another angle and I greatly appreciate your explanations in
helping me understand the Django way of thinking. So in the hope
that you now don't feel exploited… ;)

> You might be able to write a mapping to Storage that did some sort
> of naming trick (e.g., split off a colon at the end of a filename
> for read, so you could request "/my/file.txt:deadbeef" to request
> the "deadbeaf" hash of /my/file.txt") - but my point is that the
> storage API doesn't contain a *natural* endpoint for version
> information.

Arguably, the ref/hash/date could come from the config, not from the
file, and suddenly there'd be a 1:1 mapping between a filesystem
store and a storage that uses Git directly.

Sure - that could work too. Although I'd question why you'd do this, rather than just checking out the relevant hash onto the filesystem, and doing a direct filesystem read.

> And, even if you did this, what you're going to get is a view of
> your Git repository that tries *really* hard to make it look like
> just a normal file system.

Yeah, this is an excellent point, especially since I'd probably not
allow pushes to that Git repository but instead set up some sort of
polling or regular interval pulling. Then I might just as well use
a filesystem.

> def myview(request):
>     with open('filename.txt') as datafile:
>         data = datafile.read()
>     return render(request, 'my template.html', {'data': data})
>
> You're possibly getting lost by thinking that this is a "Django" thing - it
> isn't. Basic Python is always an option.

Yeah, but I would like to assume that this has been wrapped for
Django at least one "canonical" time, with all error handling done
and proper cache integration taken care of.

Because to just start off with a myview() view like you suggest
above is quickly going to become a full-time project, if you know
what I mean. ;)

Unless I'm missing some important detail, I don't see why. It's a fairly simple caching layer, and a fairly simple rendering layer. The only complexities that I can see are the ones related to accessing the Git repository - and that's the bit that isn't part of a "common" use case.

 

> > Have you seen something like this done? Is this also still best
> > done in a view?
>
> Well... yes, I've seen this done before. It's called GitHub :-)

Hehe, that was funny.

But seriously: forget about all of the Git stuff, let's just look at
the filesystem… at least in my universe, I'd like to assume that the
idea of reading marked-up data from disk, processing it, caching it
and then making the data available to templates is such an intuitive
and standard thing to do that it could even be in Django core — if
not there, then there ought to be an existing plugin for this.

 

Again - the reason that this isn't in Django is because it's not really Django's bailiwick. Response-level caching is something that should be handled at the web server level, and web servers have various ways to handle this. And if you're going to be even more ruthless about it, I'd be questioning why you've got a live Django server in the loop at all - if it's static files, "post processed", then why not pre-render the Github files to a "rendered" form (possibly in response to a commit trigger), and simply serve the pre-rendered files as static content.

Yours,

Russ Magee %-) 

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAJxq84-HogDjdv_w03qVCnv-KnNd3_9_VEce-ogCbQje8BOXMg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.