Voting in trac
Is there anyway to add a voting module to trac? A recent thread discussed ways to improve the dev process, and I think something as simple as a voting module could help quite a bit. The basic problem I'm trying to address is the divide between what users and developers feel are important. This is not to speak ill of them, since they're putting in their time for free, but it seems if any one of the developers doesn't come across a particular use case all that often, the bug report sits forever (adjust for Internet time). In the past I suggested on IRC that the team look into getting an OS project license for JIRA (http://www.atlassian.com/jira/). If you'd like an example of it actually running, you can check out the ASF copy (http://issues.apache.org/jira/secure/Dashboard.jspa). Anyway, that idea wasn't met with much fanfare. So, now I'm wondering if there might be a trac plugin or something that could be used. -- Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Consider releasing a .95 beta
On 7/27/06, Joe <[EMAIL PROTECTED]> wrote: > Hey, I'm with you 100%. I would use the development version if I > could. Unfortunately, my project manager thinks 'development' means > 'broken'. You know how those pesky project managers can be :) I don't think it's an issue of "brokeness" so much as it is that when working with a group of people, you can't be sure everyone is running the exact same version of the framework. People run svn update at different times and all that jazz. I know we've been burned once or twice by people running different versions of django. -- Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Consider releasing a .95 beta
On 7/27/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > Two-phase email? "I'd like to svn up, report back when ready." > > Or, if too large a team, cron'd switchtower/capistrano task? Heh, I'm not saying it's not doable. It is a pain in the neck though, and is alleviated by a point release. I imagine that's why most people are hesitant to do real work based on trunk. -- Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Consider releasing a .95 beta
On 7/27/06, Todd O'Bryan <[EMAIL PROTECTED]> wrote: > Read about agile development. You can release stable code without > freezing it. I guess it depends on the definition of "stable." I agree that you can have code that runs and runs well without freezing it. At some point though, you gotta baseline the API. A release gives you the confidence that the code you write isn't going to break on the next update. Now, someone had mentioned previously that an arbitrary SVN version can be chosen to baseline against. While that certainly will work, if the developers aren't willing to make that revision as stable, who are we to? Anyway, it seems the skin is off and the bones of this horse are turning to dust. Adrian seems to acknowledge the need for a release and is working to get one done. -- Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Consider releasing a .95 beta
On 7/27/06, Ian Holsman <[EMAIL PROTECTED]> wrote: > perfect is what 1.0 is for. I certainly hope this isn't the case. It'd kill me to see django get caught up with the mythical 1.0 that seems to plague so many OSS projects. -- Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Proposal: Saving SECRET_KEY in a seperate file
On 8/7/06, Joe <[EMAIL PROTECTED]> wrote: > > Wouldn't you want to put your database settings (Username and password) > in another file as well? I would be all for this. I never liked that the settings file contains both project-wide and user settings. Since it's project-wide, it gets added to the SCM. Since it contains user settings, users really shouldn't commit it back. I realize it's Python code and all that, but it seems to be a flaky default to me. -- Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Proposal: Saving SECRET_KEY in a seperate file
On 8/7/06, Michael Radziej <[EMAIL PROTECTED]> wrote: > I strongly disbelieve that any fixed scheme of storing some > settings separately will cover everybody's needs. It's easy > enough to code your own thing in your settings.py. You'll never cover everybody's needs, but you can cover the vast majority. In practice, DB settings are likely to differ per developer. Template paths may very well, too. Middleware and installed apps probably aren't going to change from developer to developer. I think the problem is that there's no real endorsed way of doing it. A note saying "such and such should appear in a user_settings.py" file would probably go a long way to alleviating some of these recurring queries. -- Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Proposal: Saving SECRET_KEY in a seperate file
On 8/7/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > We don't need a default solution for this. It's not within the scope > of this project to tell people how they should organize their settings > files. Take that opportunity to showcase your individualism. With the lack of an endorsed convention, I expect to see this question to continue to come up. IMHO, this is a common enough scenario to warrant more than a simple write-off. -- Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Proposal: Saving SECRET_KEY in a seperate file
On 8/7/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 8/7/06, Kevin Menard <[EMAIL PROTECTED]> wrote: > > I would be all for this. I never liked that the settings file > > contains both project-wide and user settings. Since it's > > project-wide, it gets added to the SCM. Since it contains user > > settings, users really shouldn't commit it back. I realize it's > > Python code and all that, but it seems to be a flaky default to me. > > I'm not sure I understand the difference between "project-wide" and > "user" settings -- would you be willing to clarify? Settings are > settings, as far as I'm concerned, and if you're distributing a Django > app, you shouldn't be bundling a settings.py file with it... Please see my message later is this thread that clarifies a bit. As an example, I would consider database settings to be a user-based setting whereas something like MIDDLEWARE_CLASSES or ROOT_URLCONF to be project-wide. To me it seems clear that there are options each developer is apt to change for a local dev environment and others that should be common for everyone. Are you suggesting that there are no common settings and each developer should manage everything himself? -- Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Proposal: Saving SECRET_KEY in a seperate file
On 8/7/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > The thing is, there's no foolproof distinction between what settings > should differ for dev environments and which ones are definitely for > production environments. You gave the examples of MIDDLEWARE_CLASSES > and ROOT_URLCONF, but those settings are almost always different > between dev and production for my own personal projects. Point is, > every developer is different, and we shouldn't waste the time in > trying to come up with some sort of framework on top of the settings > framework. Fair enough, but this isn't terribly different from how settings.py overrides django defaults. You've just moved it down to the project level. I don't think specifying project defaults and then user settings requires a whole new framework. It's basically what you already have going on. Django defaults -> settings.py -> user_settings.py With entries to the right overriding all those to the left. > If you and your development team find yourselves duplicating settings, > by all means factor them out into a common, shared settings file. Indeed, that's what we ended up doing. I'm sure we've done it differently than most others have. What's lacking is consistency to a common problem. It's nice to talk about individuality, but when I look at someone else's code, I have to put more thought into how settings are overridden than is really necessary. Is it a lot? Probably not. Is it unnecessary? I believe so. Ignoring the problem doesn't really help anyone out. I've pitched my idea above, but at the least I still think a note in the documentation, which implicitly endorses a particular method, would cut down on the number of times the question arises and otherwise ambiguity. If you still disagree, then I guess we'll just have to agree to disagree and I'll begrudgingly drop the matter. -- Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Re: [Fw]The Python Web Framework
On 8/22/06, James Bennett <[EMAIL PROTECTED]> wrote: > 1. It's easier to "switch out" pooling utilities this way, or to > switch between pooling and not pooling as circumstances dictate. When > your framework tries to do connection pooling for you, it > automatically gets harder and, depending on whether you can turn the > framework's connection-pooling utility off, maybe even gets > impossible. I've experienced the exact opposite. When I can say in a config file that I want 10 connections in a pool, that's a lot easier for me than setting up an external utility. Moreover, it works with whatever DB I happen to have configured my app to use at the time. > 2. Admittedly I don't have a whole lot of experience in the area, but > creating and managing a pool of connections to be passed from thread > to thread just feels like much more hassle and overhead than we really > need, especially since there are external pooling utilities available. It seems to me that it'd be better to discuss this at the technical level first and then worry about implementation afterward. I realize that the django devs are strapped for time, but that doesn't strike me as grounds for making everyone else solve the same problem over and over again. If it's determined that it is something that should be included in the ORM component, then maybe someone else will step up to the plate. -- Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Small concern in newforms-admin
On 7/7/07, Marty Alchin <[EMAIL PROTECTED]> wrote: > So, like many other things these days, it comes down to a bikeshed. > The Django authors built theirs the way they'd like it built, because > it's what they needed for what they were doing. If you need your own, > you're more than welcome to build your own, possibly using theirs as a > base. But it seems pretty senseless to be discussing which way should > the official distribution should be done, since it's pretty obvious > that the way it will be done is the way it's already being done. I'm not sure that makes a large amount of sense, so please correct me if I'm wrong. But, if n users want to be able to use email addresses as usernames but m developers are indifferent to it, where n is likely to be magnitudes larger than m (just because m is small), then n different people should all do it themselves and not bother with a feature request? I guess I just don't understand how it can be considered futile for users to try to enhance a feature added 3 years ago *shrug* -- Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: mod_python: Why use req.uri, not req.path_info?
I feel your pain here. I never quite understood why the app, project, whatever, had to care where it was being deployed. Or rather, why one has to go out of his way to make URLs work in different contexts. Coming from the Java world, this was something I had never run into, and I was pretty put off by it. I could map an application to any context and things just work. On IRC, I have seen this as a recurring "problem" over the past two years of my participation there. Most people respond with "configure a new subdomain *shrug*", which clearly is not appropriate for all circumstances. Alas, that's exactly what I've deferred to for simplicity's sake. So, if the change is simple enough to make, I'm +1 (non-binding) for it. -- Kevin On 7/10/07, Forest Bond <[EMAIL PROTECTED]> wrote: > Hi, > > I was trying to set up a site at a URL that is not at the root of the web > server. I am using mod_python, and my apache config looks similar to that > included with the relevant django documentation, which I'll duplicate here: > > [from http://www.djangoproject.com/documentation/modpython/] > > > > SetHandler python-program > PythonHandler django.core.handlers.modpython > SetEnv DJANGO_SETTINGS_MODULE mysite.settings > PythonDebug On > > > > That documentation correctly adds: > > "Restart Apache, and any request to /mysite/ or below will be served by > Django. > Note that Django's URLconfs won't trim the "/mysite/" -- they get passed the > full > URL." > > So, the problem is that I have to update my urls.py to include the /mysite/ > prefix in all URLs. > > This is clearly not very DRY. For me, the biggest pain is that I'm actually > trying to deploy the same project at two different URLs (with different host > parts, too). (I have reasons to do this, although they aren't incrediblly > relevevant, so I won't go into that). Since my urls.py has to be so aware of > my > apache config, I can't do things the way I want to and use the apache config > to > enable & disable access to different application fragments under each base > URL. > > All of this could be fixed by simply changing ModPythonRequest > (django/core/handlers/modpython.py) to use req.path_info instead of req.uri. > Is > there any reason not to do that (aside from breaking backwards compatibility)? > > If a change like this is in order, I assume it will be made prior to 1.0. > What > do people think about this? I didn't get much from a Google search, but it > seems hard to believe that it hasn't come up yet in the past. > > If this can be solved using some crazy middleware-type solution, I'd be open > to > that. It doesn't seem ideal to me for the current behavior to be the default, > though. > > -Forest > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFGk8pFRO4fQQdv5AwRArNzAJ9jur9ar1+vVtAgR2/+EaGsgyksvgCfZCub > 3P41eIxMRdCx/5pO7xGNCQA= > =2t4f > -END PGP SIGNATURE- > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: urlconf, strings vs. callables
On 7/10/07, Sean Patrick Hogan <[EMAIL PROTECTED]> wrote: > The "pythonic" way is a new addition to Django if I'm not mistaken. > > I personally prefer calling by string because (I'm assuming here) it doesn't > load the function unless it needs to. So, if I have a URLConf that > references 8 view functions, it only imports the one for the correct URL if > I call by string which saves me from loading 7 functions that I'm not using. > If I import them all at the top, I'm importing functions that may have > nothing to do with rendering the current page. Of course, the impact on > resources is probably minimal to none, but it still means writing less code > to call by string. Sorry to be taking this a bit OT, but you raised an interesting point. Do you happen to know what the cost impact is for importing a function into the current scope VS the cost of introspectively looking up a function? Is either cached or is this done on a per request basis? As an aside, I prefer the pythonic way because PyDev is able to give me some help with auto-completion, which tends to mean less errors due to stupid typos. -- Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: (Un)Trac
On 7/12/07, Peter Nixon <[EMAIL PROTECTED]> wrote: > > On Thu 12 Jul 2007, Jeremy Dunck wrote: > > On 7/12/07, Peter Nixon <[EMAIL PROTECTED]> wrote: > > > Am I just being dense, or is there no way in django's trac to monitor a > > > bug for changes (and receive and email when it does) or even to add a > > > bug to a "my bugs" list?! > > > > In the "change properties" section, you want "CC". > > Aha.. Hidden in plain sight. Yeap. You just want to make sure you use a junk email address. Unlike a lot of other account-based systems, your email address is going to be publicly visible. -- Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django Windows Installers
On 7/23/07, Eugene Lazutkin <[EMAIL PROTECTED]> wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Presently I maintain the Windows installer. Because of some reasons (the > main one: core devs don't use Windows) it was not included in the > official download page, so I "distribute" it manually. Send me an > e-mail, and I'll mail it back to you. > > If you want to improve on it --- you are welcome to do so. I won't be able to dedicate any sort of actual programming time to this right at the moment. I would like to suggest packaging it up as an MSI though. As an MSI, it can be pushed through an entire organization using GPO. This would be great for making sure that all devs are using the same version of django. It would also help pushing out "django as a desktop app"-type deployments. -- Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django moving from SVN to distributed VCS
On 8/23/07, Honza Král <[EMAIL PROTECTED]> wrote: > Do you really need this? I am currently keeping my own two branches in > git repository, that I synchronize with the master svn repository. > > It is very simple to do and completely painless. As you said yourself > - since there are many conversion tools, nothing is stopping you from > running your own distributed copy of the repository. That's an n VS 1 situation. There are two reasons I could see for switching: 1) Making it easier for non-committers to provide quality patches. 2) Making it easier for users to cherry-pick patches and apply them uniformly across their various environments. Obviously, if the patch makes its way into trunk, it need not be manually managed. For the former, having to set everything up manually is another hurdle to making a submission. Some may view this as a weeding out process, which is fine. I personally am not going to bother mirroring trunk in a local repository. I would, however, use a sanctioned, public one. For the latter, it's probably not the responsibility of the devs. Indeed, it would appear to be symptomatic of a larger issue and the proper fix would be to apply patches in a timely fashion. That's not to say they're not right now -- I'm just painting a picture. So, in summary, depending on what the intent is, I think it naturally leads to a conclusion. I personally am a fan of distributed systems to encourage new contributions. I'm a member of one of the Apache projects and it annoys me as a developer to no end that we set up this extra hurdle for patch submissions. Of course, everyone has their own take on the matter ;-) -- Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Time for a new release?
On 8/26/07, James Bennett <[EMAIL PROTECTED]> wrote: > I don't think it's really something that'll be voted on, at least not > in a broad general sense. If releases happened based on people in the > mailing list saying they want it to happen, we'd be on Django 3000 by > now ;) That's not exactly a terrible thing. Either listening to what your users want or providing frequent, but smaller releases. -- Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django 1.0 features -- the definitive list
On Nov 30, 2007, at 8:54 PM, Simon Willison wrote: > > On Nov 30, 6:33 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote: >> I think we ought to call the release 2.0. > > I'm -0.5 on this (if that's possible). I understand the thinking > behind it, but "1.0" isn't an arbitrary version number - it has a very > specific meaning: "the APIs are frozen, it's safe to build things > without worrying that backwards compatibility will be broken". That's > what we've been telling people for the past couple of years, and as a > result I feel it would be odd to use 2.0 to make the statement that > version numbers are meaningless after all. Apologies for chiming in late. I agree with Simon's sentiments. Moreover, if the point is that version numbers mean nothing, which is fine, then what mechanism is used to convey API compatibility between releases? Shifting to a more personal stance, I never cared much for the term "Web 2.0". It seems too gimmicky. That's largely the impression I get with a Django 2.0 without a prior Django 1.0. -- Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Better Support for static file serving via django
On Dec 12, 2007, at 3:19 PM, Robert Coup wrote: > > On 13/12/2007, Thomas Güttler <[EMAIL PROTECTED]> wrote: >> How can you check that only authorized users can access >> some files? >> >> Files which have a coresponding FileField in the model: How can >> you test that only some people are allowed to see it? >> >> Apache can't do it. Or at least it would be complicated. > > It's not /that/ complicated... > http://www.djangoproject.com/documentation/apache_auth/ > Apache auth is not all that difficult, no. Setting up access control using Location blocks and authenticating against the Django user database is a bit of an undertaking, however. It'd be nice to see the ticket Chris posted get accepted into trunk. It's still not quite as simple as Robert was initially looking for, but it's a big step in the right direction. -- Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
