How about a Django apps public repository?
Sean Schertell
given time. For example, I just hired a guy to write a really basic
newsletter app for my project. Now I'm working on a fairly typical
"upcoming events" schedule. And soon I'll be working on a simple
photo gallery that makes thumbnails as you upload, etc. I'd bet
dollars to donuts that many of you have written these apps already.
Wouldn't Django be that much sexier if it came with an ever-expanding
repository of apps that we could all share with each other? The fact
that apps are modular plug-and-play in Django is *really* cool (Rails
can't do that). So why not leverage the "pluggability" of Django's
app architecture by making a bunch of these apps public?
Am I alone on this? If I created such a repository would anyone use it?
Sean
Ian Holsman
and how I think it would operate worked out.
it's just a matter of getting enthused enough to actually sit down
and write it.
regards
Ian
--
Ian Holsman
I...@Holsman.net
http://VC-chat.com It's what the VC's talk about
Marc D.M.
> I wonder how many of us are writing nearly identical apps at any
> given time. For example, I just hired a guy to write a really basic
> newsletter app for my project. Now I'm working on a fairly typical
> "upcoming events" schedule. And soon I'll be working on a simple
> photo gallery that makes thumbnails as you upload, etc.
And I'm now putting the finishing touches on a custom FileBrowseField
that allows you to select the file in a popup. This popup has multiple
file uploading, and could do well with the thumbnailing.
I'm also using nesh's thumbnailer right now. (search the mailing lists
for it). the thumbnail template tag works beautifully.
> I'd bet
> dollars to donuts that many of you have written these apps already.
>
or soon finish.
> Wouldn't Django be that much sexier if it came with an ever-expanding
> repository of apps that we could all share with each other? The fact
> that apps are modular plug-and-play in Django is *really* cool (Rails
> can't do that). So why not leverage the "pluggability" of Django's
> app architecture by making a bunch of these apps public?
And we'd eventually have apps that build on other apps. Can you smell a
zope?
>
> Am I alone on this? If I created such a repository would anyone use it?
No you're not. I definetly +1 you on this.
>
> Sean
>
Marc DM
Giovanni Giorgi
If you need some help... drop me an email :)
fynali
spacedman
Sean Schertell wrote:
> Am I alone on this? If I created such a repository would anyone use it?
Why not just use SourceForge[1] as repository and just keep a list of
django-related projects on the django main site?
Barry
[1] Or similar.
Jeremy Kelley
>
> +1
votes+=1 # from me too! :)
--
Jeremy Kelley <jer...@33ad.org>
gpg 1024D/EAB7CA38 6FF4 483B D7EA A09C A3E0 1CE1 F0A4 8C8E EAB7 CA38
The Christian ideal has not been tried and found wanting; it has been
found difficult and left untried. - G.K. Chesterton
bax...@gretschpages.com
One suggestion, though... for us new and dumb folks, it would be good
if the apps were as standalone as possible and could really be dropped
in and started working.
Good docs would be an added bonus.
But that's just the dumb guy talkin'.
limodou
I also suggested similar subject before.
--
I like python!
My Blog: http://www.donews.net/limodou
UliPad Site: http://wiki.woodpecker.org.cn/moin/UliPad
UliPad Maillist: http://groups.google.com/group/ulipad
Daniele Spino
code... And of course It will help everybody to have a standardized
way to do things in Django...
eg. a Django Blog
Picio
2006/9/7, limodou <lim...@gmail.com>:
Sean Schertell
of folks share my sentiments. That's nice :-)
It would be really nice to hear the devs' thoughts on the subject.
Adrian, Jacob, Simon? A penny for your thoughts?
Ironically, the whole point of this idea is to avoid unnecessary
duplication of efforts -- so if you guys already cooking something up
to address this apps repository idea, please let us know! :-)
Also to devs:
If a few of us cook something up, would it be possible to have you
guys add it to official djangoproject site rather than us hosting it
off-site somewhere? (more likely to really get used if it's on the
official site).
Cheers,
Sean
:::: DataFly.Net ::::
Complete Web Services
http://www.datafly.net
bvro...@gmail.com
Ned Batchelder
(http://cheeseshop.python.org/pypi) for this? Advantages:
1) You don't have to build anything, it's already there.
2) More visibility for Django: with a Django-specific repository, only
Django developers will see the packages. In the cheeseshop, all Python
developers will see the packages, and could find Django through a
contributed package, rather than the other way around.
3) The energy we'd put into a Django-only repository could instead be
used to further the cause of the cheeseshop.
--Ned.
--
Ned Batchelder, http://nedbatchelder.com
Wade Leftwich
> Why not use the existing Python Cheeseshop
> (http://cheeseshop.python.org/pypi) for this? Advantages:
>
> 1) You don't have to build anything, it's already there.
> 2) More visibility for Django: with a Django-specific repository, only
> Django developers will see the packages. In the cheeseshop, all Python
> developers will see the packages, and could find Django through a
> contributed package, rather than the other way around.
> 3) The energy we'd put into a Django-only repository could instead be
> used to further the cause of the cheeseshop.
>
> --Ned.
>
Plus: easy_install will find your eggs in the cheeseshop.
(It has no cheese, but lots of eggs.)
-- Wade
limodou
what we want the django-repository should be first. I don't know what
django-spec repository will be like ultimately, but I think if we
setup the repository ourselvs, we can do anything we want, but for
pypi, we cannot.
And even if we setup our own django-spec repository, we can still
submit new version information of django stuffs to pypi, no one would
say that's impossible.
Jeff Forcier
although I don't wish to imply we should not be discussing it (it seems
to be one of those issues that comes up periodically).
http://groups.google.com/group/django-users/browse_frm/thread/5e5a61a14c2e519a
There was also a discussion on IRC from even farther back:
http://simon.bofh.ms/logger/django/2005/11/18/09/17
I actually wrote up some random thoughts about this issue on a personal
wiki page, and I figure I might as well throw those out now. Apologies
for the length and the formatting (it's obviously in wiki source
format).
----
re: "Djangoforge"
[The links I shared above were also pasted here at the top of the page]
>From that discussion plus a handful of others, it looks like an
official one ''is'' planned for the 1.0 release?
* Should it be official or unofficial?
** If it's official, that would be "nicer" because there would be a
mandate for it, it would be in a central location along with everything
else, etc.
** However, if official, we might run into the problem of people
expecting official support for the non-core-dev-written code contained
therein. This is probably the #1 reason to make it unofficial--or not
to have it at all, since even an unofficial one would really need to be
linked from the official site, and thus gain officiality by
association.
*** So then the question becomes, is its usefulness going to outweigh
that support concern?
** Also, I found a reference on the IRC channel from 2005.10.03 quoting
one of the core devs as saying such a thing would be a "conflict of
interest" but that they'd be happy to have someone else host it. If
still true, this would make this official/unofficial issue moot (and
the wiki-related items below would have to pertain to some non-Django
wiki).
* What should it contain? Most of these are possibilities, I'm not
necessarily saying I think they should all be included.
** Anything that does not belong in the core "contrib" directory, stuff
that is not in the official trunk code. I.e. when someone says "Why is
Common/Useful Feature X not in Django?" and the core devs do not want
to include that feature in the short/long term, someone could make one
(app/templatetag/patch) and stick it on the Djangoforge.
** Common model examples and/or fleshed-out explanations of the ones
already included in the docs. For example, how to do tags correctly
(and/or a small discussion of the different approaches to that problem
and their pluses/minuses).
** Common templatetags, such as ones for len(), 'if x in y', etc.
** Full applications, probably the primary reason people mention this
sort of project. Blog, photo gallery, wiki, etc.
* What format should it be in?
** Is there a good reason NOT to have it in the code.djangoproject
wiki? I'd say that depends on exactly what is provided (see previous
point re: what should it contain?). For simple stuff like code snippets
(templatetags, model layouts) we already have many on the wiki. Full
apps/projects would be something else--yes, you can attach archives to
wiki pages, but we probably want source control for this stuff, right?
*** Furthermore, the wiki provides, well, a wiki--built-in discussion
and unlimited expandability by the users. At least some of a wiki's
functionality is really required for this sort of thing, IMO.
** Should we use whatever OSS "Forge" systems already exist? I have not
examined them closely, but my gut instinct from using them to some
degree is that they're kinda "loud" UI-wise, plus they aren't as
collaborative as we might need (which brings us back to the wiki).
However, if good ones exist, they have theoretically solved all these
problems before and we might not want to reinvent the wheel.
** Roll something new (with Django, of course)? See previous point re:
reinventing the wheel; but a roll-our-own could, of course, provide
exactly the features we need in the way we need them (note to newbies,
this duality of thinking is why the open source community is so damned
fragmented ;)).
----
Regards,
Jeff
Sean Schertell
Google code hosting for this idea? Anyone know off the top of their
heads whether or not we'd be able to create a Django "category"
within Google or would it just sort of be lumped in with all the
other Python stuff?
Sean
Don Arbow
>
> Very interesting points. Does anyone have any thoughts on using
> Google code hosting for this idea? Anyone know off the top of their
> heads whether or not we'd be able to create a Django "category"
> within Google or would it just sort of be lumped in with all the
> other Python stuff?
There are already users hosting Django code on Google:
http://code.google.com/hosting/search?q=label:django
This link is already posted on the django website:
http://code.djangoproject.com/
Don
Jeff Forcier
medium, at least if we want any decent discussion or Web-based
documentation. Yes, one could hold discussions via the Issues, but
that's pretty gimpy for any discussion that does not fit well as a
trouble ticket. And one could just have "local" documentation in as
files included with the source code, but that's also not ideal, IMO.
I guess in my mind a Djangoforge would be a collection of Trac
instances (see e.g. code.djangoproject.com), where each project has a
wiki for discussion and documentation, source code management, etc.
That would work best for a collection of full apps. It works less well
for smaller, more atomic items like templatetags, although I suppose
one would just collect those into a handful of other Tracs (i.e. one
for templatetags and filters, one for unofficial patches/modifications
to the core Django codebase, etc).
Mir Nazim
Marc Fargas
I like the idea of the Cheeshop and more the one of different TRACs, but on the three options given, hosting TRACs is not as easy, Cheeshop and google are free.hosting a TRAC isn't. dejavu doesn't seem an option if you need to wait for an invite code for every project.
I'd rather stick on Cheeshop and keep a listing on code.djangoproject.com also the idea of keeping all small chunks like templatetags,filters and so in a single project seems really reasonable.
my 0.02
Marc.
The probability of failure of a (computer) system is exponentially proportional to the physical distance between it and the one who could fix it. -- Martin F. Krafft
Jeff Forcier
> I like the idea of the Cheeshop and more the one of different TRACs, but on
> the three options given, hosting TRACs is not as easy, Cheeshop and google
> are free.hosting a TRAC isn't. dejavu doesn't seem an option if you need to
> wait for an invite code for every project.
Well, I would imagine that many other Djangonauts have their own
cheapish hosting that they use for personal websites or other projects,
which are more than capable of handling Trac. I mean, I can't be the
only person who already has a $40/mo VPS with a ton of bandwidth
available, right?
Unless the Django community is a lot bigger than I think it is, or my
estimates of the processing power needed to host a Trac site are way
off (both quite possible, of course) I'd wager I could host such a
system on my own resources, and I'd also wager there are folks out
there with more such resources available.
Not everything has to be 100% free as in beer :)
Dan Bravender
constructing sites organized around hierarchical menus. When adding a
page, the current structure of the site shows up like this:
root node
-child node
--child of a child node
If a loop is detected during insertion, the page is moved to the root
of the hierarchy. The code is probably terribly inefficient. I
couldn't get the preorder traversal tree working to save my life, so
I devised this. Let me know what you think.
Dan
from django.db import models, connection
from django.db.models.query import Q
import pprint
weight_options = []
for item in range(-10,11):
weight_options.append([item, item])
class Page(models.Model):
parent = models.ForeignKey('self', null=True, blank=True)
title = models.CharField(maxlength=100, core=True)
slug = models.SlugField(help_text='Friendly URL', unique=True,
prepopulate_from=('title',))
alias = models.CharField(blank=True, maxlength=100)
weight = models.IntegerField(help_text='Lower weights show up
earlier in lists. If items have the same weight, they are sorted by
name.', default=0, choices=weight_options)
body = models.TextField(blank=True, null=True)
created = models.DateTimeField('Date Created', auto_now_add=True)
modified = models.DateTimeField('Date Last Modified', auto_now=True)
index = models.IntegerField(default=0, help_text='This field is
used internally to properly arrange the menu. Please do not edit this
field.')
depth = models.IntegerField(default=0, help_text='This field is
used to format the menu. Please do not edit this field.')
class Admin:
fields = (
('Page', { 'fields' : ('title', 'body',) }),
('Menu', { 'fields' : ('parent', 'weight',) }),
('Advanced', { 'fields': ('slug', 'alias', 'index',
'depth',) , 'classes': 'collapse' }),
)
list_display=('__str__', 'admin_links', 'created', 'modified',)
list_filter=('modified', 'created',)
search_fields=('title', 'body',)
ordering=('index',)
class Meta:
ordering = ('index',)
def get_absolute_url(self):
if self.alias:
return self.alias
else:
return '/pages/%s' % self.slug
def admin_links(self):
return '<a href="%s">edit</a> | <a href="%s">view</a> | <a
href="%s/delete">delete</a>' % (self.id, self.get_absolute_url(),
self.id)
admin_links.allow_tags = True
admin_links.short_description = 'Actions'
def __str__(self):
return '-' * self.depth + self.title
def ancestors(self):
list = []
page = self
while page:
if page in list:
raise 'loop detected'
list.append(page)
page = page.parent
return list
def save(self):
super(Page, self).save()
# Make sure there are no loops in the hierarchy
try:
self.ancestors()
except:
self.parent = None
# Call the super's save, so that the DB is correct before we
modify it.
super(Page, self).save()
def get_order_recurse(parent, depth, index):
pages = Page.objects.filter(parent=parent).order_by('weight')
for page in pages:
page.index = index
page.depth = depth
super(Page, page).save()
index = get_order_recurse(page, depth + 1, index + 1)
return index
index = 0
pages = Page.objects.filter(parent__isnull=True).order_by('weight')
for page in pages:
page.index = index
page.depth = 0
super(Page, page).save()
index = get_order_recurse(page, 1, index + 1)
Sean Schertell
the ground. And it sounds like a lot of folks would be happy to have
such a repository. But if we want to make it work, it has to have
some content from the very beginning. So how many of you actually
have code that you want to share? Anyone willing to make a commitment
to contribute apps if set this thing up?
I'll start with the following three:
Newsletter: A handy newsletter app for (opt-in) mass mailing
BasicAuth: A simpler authentication system for people who use a
custom admin site
StaticPages: A very lightweight request to template mapper (similar
to TemplatePages)
Any other contributors?
Sean
:::: DataFly.Net ::::
limodou
>
> I'm willing to invest the time and bandwidth to get this thing off
> the ground. And it sounds like a lot of folks would be happy to have
> such a repository. But if we want to make it work, it has to have
> some content from the very beginning. So how many of you actually
> have code that you want to share? Anyone willing to make a commitment
> to contribute apps if set this thing up?
>
> I'll start with the following three:
>
> Newsletter: A handy newsletter app for (opt-in) mass mailing
> BasicAuth: A simpler authentication system for people who use a
> custom admin site
> StaticPages: A very lightweight request to template mapper (similar
> to TemplatePages)
>
> Any other contributors?
>
> Sean
>
Jeff Forcier
>
> Any other contributors?
I've got a handful of templatetags, which while somewhat outdated
(built against ~0.91) should still be useful. I also have a (very)
small forums app which I plan on expanding when I find the time,
although it would need some cleanup to use outside of the site it's
currently in.
There are a couple of other things I've written up but one of them
sucks and the other one is really just documentation which should go in
a blog post or on the Django wiki.
Marc Fargas
Well, I would imagine that many other Djangonauts have their own
cheapish hosting that they use for personal websites or other projects,
which are more than capable of handling Trac. I mean, I can't be the
only person who already has a $40/mo VPS with a ton of bandwidth
available, right?
You're not alone! I also have a server out there which currently only handles a mailling list... (the HD broke down and hadn't had time /willing to upload my site again, I'm watting for a nice blog app for django for that.. hehehe)...
Unless the Django community is a lot bigger than I think it is, or my
estimates of the processing power needed to host a Trac site are way
off (both quite possible, of course) I'd wager I could host such a
system on my own resources, and I'd also wager there are folks out
there with more such resources available.
Maybe the community is big, but sure there are not "too many" contributions to kill a server ;) Maybe the biggest issue is to automattically create trac's and subversion repositories but it shouldn't be too hard. So if there is a common willing of getting this up we can go over it! And with two servers at least we can do backups ;))
Not everything has to be 100% free as in beer :)
Maybe someday... someday near 2111011.
By the way, to the djangoproject.com DNS admin, would it be possible to get a CNAME for contrib.djangoproject.com ? ;oP
The question: Who would really like, and activelly support that initiative? (having a repository of un-official templatetags, filters, patches and applications)
charles sibbald
We could probably use this, I currently have it set up to serve VPS's specific to Django and would be willing to use it also for this purpose.
Sean Schertell
bandwidth and servers for hosting this stuff. ;-)
But what about the actual stuff? So far we've got a couple people
willing to contribute an app or two. And as I've said, I've got three
I can put in to get started. I run a smallish web hosting company so
I'm happy to provide the servers/bandwidth. What we really need is
apps and folks who want to contribute ideas or actual code to making
the space. So how about it guys? Got apps you wanna contribute? or
ideas for how this thing should work? anyone wanna volunteer to help
build it?
:-)
Sean
> possible to get a CNAME forcontrib.djangoproject.com ? ;oP
Marc Fargas
Funny how in a "room" full of web developers, lots of us have
bandwidth and servers for hosting this stuff. ;-)
Sure, right now we have 4 volunteers to provide the hosting and bandwidth, including a Tier 1 o_O now it's time to look about who will provide the contents (that is, code for the repositories!) and see how to get this up and running.
The option given of hosting a TRAC + svn for "big" things like big applications, and having common TRAC+svn for small pieces like filters and templatetags, etc, seems the more reasonable. But this would need a group of volunteers to keep the thing on (that is some 'admins' to make sure things don't break down) so the volunteers that put the hosting in place have a bit of help on that. Also we'd have to think on how to make things easier for people, not all contributors will know how to set permissions on a svn repository or a TRAC project so providing an easy way to give such permissions would be thankfull!
So, the questions open now:
* How has code, or nice ideas, willing to contribute and mantain and would be pleased of setting this thing up? (some people prefer to host their code on their server)
* How has the knowledge and the willingnes to help setting-up and maintaining the service itself?
Right know I have no code so I'll be volunteer for point two ;)) Also on that point we'd better meet in IRC or start another thread to break the more technical thing apart.
Cheers,
Marc.
Jeff Forcier
however, in my opinion a substantial chunk of the usefulness for such a
project is to also provide a common ground for *developing*
contrib-type apps. In addition, it might be worth our while to seek out
some folks listed on the wiki and/or here on the mailing lists, as
having created or started a "common" app (I recall a wiki, for example,
and I know Ian H is/was working on his own forums app) and attempt to
recruit their work for this repository.
That brings up another issue--what's the best way to deal with multiple
attempts at the same problem? I could see things go either way,
side-by-side versions or flavors of similar apps (all the messageboards
go over here, all the wikis go over here) or a strong emphasis on
trying to get people to merge their projects. Obviously this is a
thorny issue, and has been ever since the first open source project
forked, but we should probably still think about it at some point.
As for maintenance/setup of the repository itself, I'd be willing to
lend a hand, I seem to be setting up a new Trac instance every month or
so, albeit primarily for single-user scenarios.
I'm on #django during the week, I can't promise to be in there much
this weekend; I'd also be up for another GoogleGroups thread if we
really do need to split the technical stuff out of this thread
(honestly I don't care much either way).
Regards,
Jeff
Sean Schertell
I can get started in October putting this together. I have servers,
bandwidth, and general webdev skills. I've registered djangoforge.net
for us to use, and I can commit to maintaining the site.
Any other volunteers for helping to develop the system? Any other
apps contributions?
Also, more thoughts on how you'd like to see this implemented would
be much appreciated. How would you like this site to work? What
features do we need at a minimum?
Thanks!
Sean
:::: DataFly.Net ::::
Ian Holsman
I just need to add some basic templates for it.
Give me a day or two to get it up ;-)
regards
Ian
--
Ian Holsman
I...@Holsman.net
http://zyons.com/ build a Community with Django
limodou
>
> I've nearly got something together now.
> I just need to add some basic templates for it.
>
> Give me a day or two to get it up ;-)
>
Sean Schertell
Could you let us in on how it's gonna work, what your plans are?
Sean
Marc Fargas
If you, or another volunteer can setup a system (debian etch
preferred) I can go on configuring the mailling lists, the TRAC
hosting, SVN repositories and so on (and some scripts to manage them).
It would be better to use a VPS on its own for security.
So, if anybody has a spare debian etch VPS around there ... ;)) Then
we can get what Ian is working on and tie everything toghether. I'll
be on IRC during the afternoon (telenieko)
Cheers,
Marc.
Russell Keith-Magee
>
Russ %-)
charles sibbald
1. Full projects
2. Useful Classes
3. Useful Functions -
similar to a mini hotscripts, sometimes someone has written a great project/application but no one has the time to trall through to look for particular featureful classes/functions, and it would be great to have the ability to list these seperately when one feels they have had a stroke of genius and have written a class/function they feel is simply amazing.
Also can we have a forum rather than mailing lists, they are anoying and not the easiest to store knowledge on problems/resolutions
regards
charles.
From: Marc Fargas <tele...@gmail.com>
To: django...@googlegroups.com
Sent: Monday, September 11, 2006 1:26:25 PM
Subject: Re: How about a Django apps public repository?
Marc Fargas
middlewares...)
Forums sucks, any decent mail client can show a list ordered by
threads, and any mail manager can create archives for a list easy
searchable by Google. Any decent python script can send mails to
mailling lists on svn commits. Sincerelly, forums are anoying.
mailling lists rock. Look at googlegroups. Those are mailling lists,
you can use them as forums if you wish. But you are free to use lists
off-line, save them on the disk, forward a message, CC it to somebody
already interested and so on.... No matter on a list <> forum
interface, but forums alone suck. List managers rock!!
Ian Holsman
On 11/09/2006, at 10:53 PM, charles sibbald wrote:
> I think Djangoforge should have the ability to host projects as
> follows:
>
> 1. Full projects
> 2. Useful Classes
> 3. Useful Functions -
>
> similar to a mini hotscripts, sometimes someone has written a great
> project/application but no one has the time to trall through to
> look for particular featureful classes/functions, and it would be
> great to have the ability to list these seperately when one feels
> they have had a stroke of genius and have written a class/function
> they feel is simply amazing.
>
> Also can we have a forum rather than mailing lists, they are
> anoying and not the easiest to store knowledge on problems/resolutions
ok..
i have a slightly different idea.
there are enough places to host a open source project.
a) python-hosting
b) sourceforge
c) google
the world would not be any better having another SVN/Trac for a
project. also people won't move their existing project
just because we offer a forge.
What I was thinking of was more a directory of projects. more just
storing the meta-data like
mailing lists locations, release information, projects it relies on,
and projects which use it and stuff like that.
we could then aggregate this information to provide a centralized RSS
feed on top of it so people can keep track of
new releases and new projects.. as well as a way for people to
search and browse through the list of projects, so they
can find what they need.
regards
Ian.
--
Ian Holsman
I...@Holsman.net
http://peopleintopoker.com/ -- where the poker people go
charles sibbald
regarding forums/mailing lists, if we can have a forum/mailing list interface then thats great.
Marc Fargas
provide that svn+trac that some people was interested in, and to put
the snippets inside. And setup something like a "django portal" with
not only information about what is inside the repositories but also
projects, applications and so that are outside the site. That way
newcomers and users have a unique place to find everything they want.
And those who don't know/want to setup SVN and TRAC can getit for
their django projects.
And surely we can skip the mailling list part as I don't thing there
would be too much volume that could not be help by that group or
another. Mabe *-commit lists if somebody wants it.
So "A central location for all django contributed work, and a place to
host your project" ;)
Cheers,
Marc.
On 9/11/06, Ian Holsman <kry...@gmail.com> wrote:
Joeboy
last time I asked this question:
http://groups.google.com/group/django-developers/browse_frm/thread/5b5b9070f8ca36d7
If I submit a reusable app, should its views pass a RequestContext to
the templates or not? If they don't, they'll break projects eg. with
templatetags that require request information. So if our apps have any
aspirations to reusability, does that mean we should *always* pass
RequestContexts, and that vanilla Contexts are essentially deprecated?
Joe
Marc Fargas
On the linked thread have you checked: http://www.b-list.org/weblog/2006/06/14/django-tips-template-context-processors ? You can use a context processor to make {{ user }} available on all templates.
Cheers,
Marc.
James Bennett
> willing to contribute an app or two. And as I've said, I've got three
> I can put in to get started. I run a smallish web hosting company so
> I'm happy to provide the servers/bandwidth. What we really need is
> apps and folks who want to contribute ideas or actual code to making
> the space. So how about it guys? Got apps you wanna contribute? or
> ideas for how this thing should work? anyone wanna volunteer to help
> build it?
I've got a few things I'm building, but I'm still a ways out from
releasing any of them publicly and I've also got hosting with easy
access to set up SVN repos...
That's the "problem" with having a relatively savvy developer community :)
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
limodou
Joeboy
> http://www.b-list.org/weblog/2006/06/14/django-tips-template-context-processors?
> You can use a context processor to make {{ user }} available on all
> templates.
Unless I'm missing something, that link says the same as what I'm
saying, namely that you need to use RequestContext everywhere if you
want your apps to be pluggable.
Now, this seems to me to be a rather crucial and earth-shattering,
given that
a) It means basically abandoning the principle of keeping data nicely
partitioned and making stuff available 'everywhere'.
b) I don't think the django tutorials even mention RequestContext once;
I don't really understand why no-one apart from me seems to think this
is important. Now, I'm a huge django fan, but frankly this seems like
the kind of skank that repelled me from all the php frameworks I tried
(and yes, I'm trolling in the hope of getting some kind of response...)
Joe
Marc Fargas
Look at the example carefully:
In myapp/context_processors.py
| 1 | def media_url(request): |
| 2 | from django.conf import settings |
| 3 | return {'media_url' : settings.MEDIA_URL} |
And in settings.py
On your case you would maybe want to return 'user': request.user
> As far as I can tell the way to do this is to modify *every* *view* *in* *my* *project* to pass
> either the user or a RequestContext.
The link I gave you is to not do that, but add a processor that will add the user to the context.
Joeboy
>> *view* *in* *my* *project* to pass either the user or a
>> RequestContext.
>
> The link I gave you is to not do that, but add a processor that will add the
> user to the context.
I think you might be missing the bit that says:
"Finally, we change our view code to use RequestContext instead of the
base Context class."
Joe
Marc Fargas
I think you might be missing the bit that says:
"Finally, we change our view code to use RequestContext instead of the
base Context class."
You're right! I missed it, then there's no easy solution for your problem ;o)
Joe
Marc
Jeff Forcier
> I agree on those, maybe the greatest thing to get on would be to
> provide that svn+trac that some people was interested in, and to put
> the snippets inside. And setup something like a "django portal" with
> not only information about what is inside the repositories but also
> projects, applications and so that are outside the site. That way
> newcomers and users have a unique place to find everything they want.
> And those who don't know/want to setup SVN and TRAC can getit for
> their django projects.
>
> host your project" ;)
This and Ian's point is good, that we should not necessarily expect
people to migrate from their existing svn hosting to a new one. So I
think an abstracted layer of sorts would make sense--something that
obscures whether a project's SVN/Trac is at Djangoforge, or at an
external location--and that way from the perspective of "I need to find
a project/app/snippet that does X", the site is uniform, and the nitty
gritty of where you actually get the code is dealt with later on.
The primary issue with referencing external code is that there might
theoretically be some sort of legal or permissions related issues. I
know that it is not *illegal* to link to other peoples' publicly
available URLs, but it's still nice to ask first, especially when there
is metadata associated with it (description, list of authors,
tags/categories, etc, etc).
And finally, yes, there is still the issue of A) providing hosting for
people who cannot or will not host a project themselves (or who, like
myself, sometimes keep "specific" versions of their apps locally and
who would prefer to publish a "modular" version on a site like
Djangoforge) and B) dealing with more atomic stuff, i.e. the "snippets"
of templatetags/filters, model examples, etc.
I'm still unsure how much of this is treading on what should be the
current Django wiki's territory; it's already capable of referencing
existing projects and storing code snippets, so with some sort of
"project listing template" all that Djangoforge would offer extra is
the actual hosting for folks without any--which, yes, Google Code and
friends already provide.
Hmm.
-Jeff
know...@gmail.com
I don't have a place where I can test this right now. Do you have a
site that illustrates what you're trying to do?
Thanks
Mark Underwood
[frameworks : django : navigation]
Lucas Vogelsang
Is this project/thread dead or is someone working on it?
I'd like to use this repository, however I am fully tied up with my
other projects and can't help pushing it forward.
regards,
lucas
>
Steven Armstrong
looks like all the others have the same problem ;)
Marc Fargas
I was waitting for Ian Holsman who said had something on pending of
some 'styling', if no body is on it I can take over it ;)
Cheers,
Marc.
Sean Schertell
I'm the guy that started this thread and had pledged to take the lead
on this. Ironically, I'm also the guy who started the recent thread
"Why I'm giving up on Django". So for now, it looks like I'll be
taking an indefinite hiatus from Django dev.
If someone wants to take this idea and run with it, I think that
would be great. Then down the road sometime when Django's little
idiosyncrasies are resolved and I come crawling back to the platform,
maybe there will be a repository all ready to rock too!
If anyone is seriously interested, I've registered the domains
djangoforge.com, .net, and .org. I'd be happy to donate those to the
cause along with my apps so far.
Best wishes,
Sean
Kenneth Gonsalves
On 01-Oct-06, at 9:08 AM, Sean Schertell wrote:
> I'm the guy that started this thread and had pledged to take the lead
> on this. Ironically, I'm also the guy who started the recent thread
> "Why I'm giving up on Django". So for now, it looks like I'll be
> taking an indefinite hiatus from Django dev.
just curious - did you indulge in all this fanfare when you left PHP
for django?
--
regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/web/
Sean Schertell
>> on this. Ironically, I'm also the guy who started the recent thread
>> "Why I'm giving up on Django". So for now, it looks like I'll be
>> taking an indefinite hiatus from Django dev.
>
> just curious - did you indulge in all this fanfare when you left PHP
> for django?
Fanfare? Not sure what you mean really. The only reason I added to
this thread again was because I have some domain names I'd like to
donate which might be useful to the community.
I posted publicly about giving up on django because I thought it
might help air out some niggling issues in django. I was also curious
to see if I was the only one struggling with these issues or if these
were actually problems worth addressing. I certainly didn't mean to
offend anyone or to "indulge" myself in any way.
Best wishes,
Sean
Ian Holsman
On 02/10/2006, at 11:42 AM, Sean Schertell wrote:
>
>>> I'm the guy that started this thread and had pledged to take the
>>> lead
>>> on this. Ironically, I'm also the guy who started the recent thread
>>> "Why I'm giving up on Django". So for now, it looks like I'll be
>>> taking an indefinite hiatus from Django dev.
>>
>> just curious - did you indulge in all this fanfare when you left PHP
>> for django?
>
> Fanfare? Not sure what you mean really. The only reason I added to
> this thread again was because I have some domain names I'd like to
> donate which might be useful to the community.
I've been sidetracked on other (non-django) issues.. hence why i've
been silent on the list
when I can get my head out of the water for a period I'll release
what I have.
regards
Ian.
--
Ian Holsman
I...@Holsman.net
http://car-chatter.com/ where car fanatics meet
Kenneth Gonsalves
On 02-Oct-06, at 7:12 AM, Sean Schertell wrote:
> I posted publicly about giving up on django because I thought it
> might help air out some niggling issues in django
you have not answered the question. When you left PHP, did you post
publicly to help air out some niggling issues in PHP, like for
example, in your words 'a feeling of coding underwater'. And why i am
raising this is, simply, you could have raised your seven issues
without the drama of saying you are leaving etc etc - we would have
taken them seriously anyway. We are building up a good framework and
an excellent community and it ill behoves you to create a thread with
a subject line like the one you produced on django users.
Sean Schertell
>> might help air out some niggling issues in django
>
> you have not answered the question. When you left PHP, did you post
> publicly to help air out some niggling issues in PHP, like for
> example, in your words 'a feeling of coding underwater'.
I didn't post to any PHP community when I left because (a) I wasn't
an active member of any PHP mailing lists (b) I didn't really have
anything to say about PHP that hasn't already been said a thousand
times before so I didn't think it would be very useful to anyone. I
reached a point with Django where I felt I couldn't finish my project
so rather than just leaving silently, I thought maybe I could help
out in some small way by explaining why. It certainly wasn't meant as
an attack of any kind.
> And why i am
> raising this is, simply, you could have raised your seven issues
> without the drama of saying you are leaving etc etc - we would have
> taken them seriously anyway.
Point taken. I apologize if I came off sounding dramatic. I really
didn't mean to but I was admittedly a little frustrated at the time.
I guess that may have come through in my delivery.
> We are building up a good framework and
> an excellent community and it ill behoves you to create a thread with
> a subject line like the one you produced on django users.
A good framework? Are you kidding?! You guys are building up the
*killer* framework to put all other frameworks to shame! Just because
I pointed out a couple issues that I had trouble finding my way
around doesn't mean I don't think Django totally rocks. It does! It's
just that for my working style, I'll have to wait until a few things
are "fixed" before I can use it effectively.
Anyway, that's all from me for now folks. Sincere best wishes to all
and huge thanks to the Django devs. I can't wait to see where this
framework is headed.
Cheers,
Sean
Jeff Forcier
This issue came up yet again on the IRC channel today, and myself,
jesusphreak and a couple of others did yet more brainstorming, partly
recycling earlier topics and partly moving things forward even more.
It started about here:
http://simon.bofh.ms/logger/django/2006/10/04/15/30/
and then the "meat" of the discussion--skipping me being dense about
Amazon S3, and some rehashing of earlier arguments--here:
http://simon.bofh.ms/logger/django/2006/10/04/16/09/
Please take the few minutes to read through that discussion, as I
doubt I'll remember to touch on everything in this email.
Before getting into specifics, I have two requests:
Sean, if you're still listening, can you please contact me to
negotiate transfer of the domain names? Even if I'm not the eventual
recipient of the registration, I'd be glad to at least take them off
your hands for the time being.
Ian, if/when you get time to read this stuff over and examine your own
code, I'd just like to know what it looks like so I know how much we'd
be duplicating work already done. No pressure, though! :) I tend to
like writing my own stuff anyways (then again I think we're all like
that to some degree).
The basic gist is as follows:
* Set up a combination Trac farm / web-app directory system.
* Each app/project is stored in a Trac instance, complete with all the
Trac goodness that is a SVN repository, wiki, tickets, and etc.
* Each app *also* has an entry in a front-end directory, which
contains:
* metadata about the app - author[s], categor(y|ies)/tags, etc
* a direct package download - ideally, one automatically generated
from a tagged release in the SVN repository
* a link to the "backend" Trac instance for the project
* a comments section for those who just want to leave a note about
the app without really contributing full-fledged documentation to the
Trac wiki
* The directory front-end app will necessarily aggregate the info for
all the apps, providing various views to the data (e.g. "list all
blog-related apps, and snippets", "show recently added apps", etc).
Such a setup would provide the following benefits:
* Ease of use/accessibility:
* For users, the ability for one-stop shopping for pluggable apps,
via the package download. The fact that apps are stored in SVN doesn't
matter - they will still be able to grab the latest version of the
app, with access to older versions if desired (similar to Sourceforge)
as a ZIP or TGZ or egg or whatever.
* For developers who want to just donate a singular version of an
app and never touch it again, and/or who are not SVN-literate,
curators (or an automated system, theoretically) can take an archive
file and create a new project out of it, with no further action on the
part of the original dev.
* For developers who are SVN-literate, it will be the same as any
other SVN or CVS like setup--they will get the keys to their
particular Trac kingdom and can go to town.
* Flexibility in storage: some folks don't like the idea of having to
use SVN to get access to things, others don't like the fact that
flatfile-based storage is terrible at versioning and so forth. This
approach mixes both so that folks who just want to grab a .zip, can,
and those who want to get SVN access, can.
* The usual *forge-like directory interface: unlike *just* a Trac
farm, as I originally mentioned, this setup allows us to have a facade
in front of the Trac farm, so that we get all the metadata and
organization and searching that is useful for something like this.
* Note that unlike actually using Sourceforge or Google Code, we
can customize this setup to behave the way we want. Google Code does
not provide even a tenth of the functionality Trac does, and
Sourceforge does not allow us to specify our own metadata for
organizational purposes (plus its interface is, IMHO, very cluttered).
I am willing to start hosting something like this as soon as it can be
built, on my own dinky little VPS; I recall that Marc Fargas and a few
others also volunteered hosting. In that case, I'd still like to
volunteer my time and what little expertise I have, to
running/curating the thing, as well as writing the front-end or
modifying what Ian has started with.
Thoughts?
Regards,
Jeff
Lucas Vogelsang
Hash: SHA1
Hi,
We have discussed together a bit and sorted some things out.
Here's a little update:
To stop spamming the mailing list, we created a new one:
djang...@golfos.net
To subscribe visit this page:
http://golfos.net/cgi-bin/mailman/listinfo/djangoforge
If you prefer to chat, we have our own irc channel on
irc.freenode.net: #djangoforge
If you are really interested in developing, we suggest, that you join
the launchpad team: https://launchpad.net/people/djangoforge-devs and
read the wiki page:
http://djangoforge.vincisolutions.org/wiki/page/frontend-object-spec/
So, if you have any ideas or just would like to watch the discussion,
go to one of the listed communication channels!
I hope we have something up that will meet your needs as soon as possible!
regards, lucas
Jeff Forcier wrote:
> Howdy folks,
>
> This issue came up yet again on the IRC channel today, and myself,
> jesusphreak and a couple of others did yet more brainstorming,
> partly recycling earlier topics and partly moving things forward
> even more. It started about here:
>
> http://simon.bofh.ms/logger/django/2006/10/04/15/30/
>
> and then the "meat" of the discussion--skipping me being dense
> about Amazon S3, and some rehashing of earlier arguments--here:
>
> http://simon.bofh.ms/logger/django/2006/10/04/16/09/
>
> Please take the few minutes to read through that discussion, as I
> doubt I'll remember to touch on everything in this email.
>
> [ ... ]
>
> Thoughts?
>
> Regards, Jeff
>
>
> >
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Signed with GPG & Enigmail - see http://www.vincisolutions.ch/pgp/
iD8DBQFFKpLI3RQ/RpGW2HgRApelAJ0eaZ21y6mIs59EDn6pOlxoCGGbHgCcCPZu
iU2DrKyMThgW2OwUQA40Ppk=
=q0kU
-----END PGP SIGNATURE-----