Re: Composite Fields
Malcolm, I strongly concur with the proposed API. It looks like it can be used to implement future RangeHash partitioning support. Consider: I have a model to be partitioned that has an IntegerField that will become the range partitioning value: week = models.IntegerField() # 1 to 53 depending on the week of creation The hash partitioning value is a field that works precisely like "id": hash_id = models.IntegerField( auto_everything=True ) # (I made "auto_everything" up as I am not sure precisely what parameters I need to set in order to make this happen.) Now I can create my RangeHash partitioning primary key with a compositeField: range_hash = models.CompositeField( hash_id, week, primary_key=True ) What I am doing today for my partitioned models is to use the automatically generated "id" field, but that looks dicey with the CompositeField since you can't do this: range_hash = models.CompositeField( id, week, primaryKey=True ) since "id" doesn't exist yet and, by designating this CompositeField as the primary key, id won't be generated. Rather than try to special case this situation, ensuring that I can create a field that works precisely like "id" by hand and then using that seems to be the way to go. Rock --~--~-~--~~~---~--~~ 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: I want a pony: Django Cheeseshop
Great mail ! This has to be published somewhere like Jacob is suggesting. I'd like to react on the PyPI part: On 15 sep, 04:52, Kevin Teague <[EMAIL PROTECTED]> wrote: > > PyPI > - > > Everyone knows what this is (hopefully!). A small point to note is > that it was originally called The Cheeseshop, there was a long thread > started by people who didn't like the name, and it was renamed to PyPI > and use of the name Cheeseshop is politely discouraged. > > While there is only one PyPI, tools that pull packages from here > (easy_install and buildout) can easily pull from additional package > repositories. These can be mirrors, local caches, private repos, or > whatever. Creating your own repo is as easy as dropping a Python > packaged .tar.gz file into a directory and exposing it using Apache's > default directory views feature. There are also cool projects recently > started such as z3c.pypimirror which lets you create a local PyPI > mirror, but rather than mirror all 4+ GB of PyPI, it will only mirror > packages *as you request them*, very cool and probably something that > would be quite neat in a shared hosting environment. As far as I know (and as I said to Andreas Jung when they created this package during a sprint lately), z3c.pypimirror is a *full* mirror. It doesn't allow you to get only some packages. It has a name filter, so you can get for instance all package that starts with "foo." but this is a non sense because this package might have a "bar" package in its dependency, it won't grab it. So basically it is a rsync, and rsyncing 5 gigas is taking a bit of time (I think they are taking care of this aspect now, I am not sure though) We developed before z3c.pypimirror a package called iw.eggproxy that is a proxy that will simply get all the package tools like easy_install or buildout are asking for. So if you work in a zope environment it will get only the package you work on. > > Django really needs to update their PyPI page - it hasn't been updated > since 0.91! And it's not classified under the Frameworks::Django trove > either: > > http://pypi.python.org/pypi/Django/ > > As far as "flooding" PyPI with packages, Zope2+Zope3+Plone has 1,236 > packages on PyPI right now. There have been one or two grumbles about > this (it would seem people will grumble about just about anything), > but I'm pretty sure the consensus is if the number of packages becomes > unwieldly, the solution is to improve PyPI itself and not "start more > PyPIs". > > The only valid grumbles about heavy PyPI usage are: packages with > really sparse classification and documentation, releasing -dev > packages onto PyPI (don't do this!), and especially *don't remove a > older packages* (really please, please don't do this!). > > Plone add-ons were released to the Plone Software Center before PyPI > existed. Tarek Ziade has done awesome work at making it possible to > seamlessly release Plone add-ons to both plone.org and PyPI. This way > a package can have additional Plone-specific metadata, but still have > a PyPI presence without creating a bunch of extra maintenance work for > the add-on developer. I tried to use PyPi software at first but it was hard to reuse. I have created this PloneSoftwareCenter extension in order to be able - to make plone.org accept eggs through distutils calls, like you said (otherwise the products section of plone.org is doomed, facing pypi's one) - to run my own PyPI for private packages But there's a very important point about this work: I don't want PyPI to be a single point of failure. PyPI server is pretty robust, but I don't want my developers to depend on it while they are working. It happened in the past that we couldn't work because of that, because zc.buildout grabs a myriad of eggs at pypi to build Plone, and because we are building and upgrading buildouts all day long. (We have mirrors and caches everywhere now ;) ) Our strategy for the future on this will be to be able to use distutils/setuptools and zc.buildout with several packages indexes (pypi, plone.org or any other), and to push packages on several places and sometimes with extra metadata like you said (plone.org will have a rating system) I have changed Python 2.6 for that (http://tarekziade.wordpress.com/ 2008/05/12/the-new-pypirc-format-in-python-distutils/) so you can deal with several pypi-like servers and I have a patch in setuptools that is pending, so easy_install can play with several servers as well/ So basically, a developer will be able to push any package to any server, and a tool like zc.buildout or easy_install will be able to get a package from a list of pypi-enabled servers. (and if one of them is down , the package might be in to another one) So if you decide to deploy Django like zope, at pypi, I would encourage you to set up your own community pypi-like server, like we are going to do on plone.org. The work done on python, setuptools, zc.buildout and Plone.org to make this possible in Plone
Re: Inline formsets unique(_together) validation problems
I'll take a look at this, the reason the second part didn't go in originally(yeah, we thought of it), was that it was considered to be in a different scope then the rest of the work on unique validation. On Sep 16, 7:14 am, mrts <[EMAIL PROTECTED]> wrote: > A bug in 1.0 makes unique_together constraints fail at database level > (resulting in exceptions) instead of being caught at form validation > level. > > The bug is detailed inhttp://code.djangoproject.com/ticket/8882 > > I expect that the model validation implementation problems Honza has > are also related to this:http://code.djangoproject.com/ticket/6845#comment:30 > > Another problem is the unique constraint -- if the inline formset > contains several forms with an colliding unique field that does not > yet exist in the db, validation fails as the uniqueness checks are > done before saving them in bulk (i.e. no validation in between the > individual forms). > > Before I dig into this deeper, is someone already working on this or > does have an idea how to tackle this? Brosner? --~--~-~--~~~---~--~~ 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: I want a pony: Django Cheeseshop
On Sep 16, 2:10 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Tue, 2008-09-16 at 00:16 -0700, mrts wrote: > > Let me try to wrap this up: > > > * there seems to be a general consensus that amending setuptools to > > create Django-specific extensions is not required > > * a separate repository is not required, apps should be published to > > PyPi Famework :: Django category but a central site that tracks the > > apps there to further classify, rate and enhance them would be useful > > (like djangoplugables.com) > > * app naming and namespace issues should be resolved (should all apps > > have a django-prefix, the de facto standard? should they live in > > django.apps namespace?) > > As others have pointed out, this isn't necessary and would be bad > practice. Everybody should feel free to use whatever namespace they like > to avoid clashes and so that we avoid lowering the quality of the Django > brand (as soon as somebody installs a few low-quality "packages" and > they misbehave in any way, it's going to be "Django is a pile of > rubbish" because it's all coming from the Django namespace). Another issue I have with this: we grab generic toplevel names like "tagging", "registration" etc for apps that are coupled to Django. Semantic names that clearly state the purpose of a package help to make code more readable are of course good. But what if TurboGears people want to name their tagging app "tagging" as well (instead of Tasty as it's named now)? Ideally, I'd like to see code like this: from djc import tagging # or `from django.apps import tagging` def foo(): tagging.do_bar() # OK, at a glance I can see that this line relates to tagging instead of import tasty # `import tasty as tagging` *can* be done, but oh well... def foo(): tasty.do_bar() # What is tasty?! *Waste time for looking it up* Aha, this line is for tagging Also, there may be differences in toplevel generic `frobnicate` (usable in Python in general) and `django.apps.frobnicate` (coupled to Django and packaged as django-frobnicate) that adapts the former to Django. --~--~-~--~~~---~--~~ 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: Proposal: Enhanced simple-tag decorator #1105
On Sep 16, 1:03 pm, Julien Phalip <[EMAIL PROTECTED]> wrote: > This is a call to review ticket #1105. The proposed patch is fully > functional, backwards-compatible and contains tests and > documentation.http://code.djangoproject.com/ticket/1105 > > Currently it is not possible to access the context from within a > simple_tag, and there is no "simple" way to create block tags. Both of > these tasks imply using some boilerplate code to parse the tokens, > manage variables, etc. +1, I love it. I've been using this in my own projects for ages. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Proposal: installmedia command - A story for distributing media with apps
Distributing media with apps could be a lot easier. Currently this requires copying or linking files manually (possibly each time the app is updated), and this encourages developers to put CSS and JavaScript inline in their templates. I propose a management command to make this easier: $ python manage.py installmedia appname [appname ...] The command is "dumb." It goes like this: - Read MEDIA_ROOT from settings.py. - Look for a 'media' directory in the app. - Copy or link everything in there to MEDIA_ROOT. This simple command saves you quite a bit of typing. Some possibilities... - Switches like --copy, --link, --overwrite, etc. - Just like with templates, it could become best practice for apps to have their media structured like so: media/ media/appname/ media/appname/css/ ... - Or in the simple case: media/ media/css/appname.css media/css/appname.js This should make it easier for apps to make assumptions about where their media is located relative to MEDIA_URL (this is currently ad hoc). Thoughts? --~--~-~--~~~---~--~~ 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: Proposal for 1.1: Extend inclusion tag syntax to allow custom templates (#9093)
On Sep 16, 8:37 am, "Justin Lilly" <[EMAIL PROTECTED]> wrote: > I don't think anyone will complain that they have to type less, as its > still understandable. +1 for allow_override. Changed to allow_override. See patch #4 at: http://code.djangoproject.com/ticket/9093 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Install over old level produces mutant
We've had at least three people run into a problem (#9090) after installing 1.0 over an old level. Now, we do document that before installing you should remove any old level. But I find the results when you don't rather odd. It's not just old files renamed/deleted in the new level that wind up being 'leftover' in the site-packages directory. Rather, some files that exist in both levels, and changed between the two, are not updated by install. So you wind up with a mixture of 0.96.x and 1.0 level files, which is pretty confusing and subject to odd failures. Does anyone know if there is something we could do to prevent this situation? I'm not very familiar with Python installation procedures. It seems like it would be better, though, if our installer flat-out refused to install over a pre-existing installation or offered to delete the pre-existing install before continuing with the new install. What's the norm for Python packages? Karen --~--~-~--~~~---~--~~ 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: Install over old level produces mutant
We could definately have it do the check pretty easily just by shoe horning some stuff at the top of setup.py, actually offering to uninstall might be more complicated, although it could probably be done in the same way. On Sep 16, 1:20 pm, "Karen Tracey" <[EMAIL PROTECTED]> wrote: > We've had at least three people run into a problem (#9090) after installing > 1.0 over an old level. Now, we do document that before installing you > should remove any old level. But I find the results when you don't rather > odd. It's not just old files renamed/deleted in the new level that wind up > being 'leftover' in the site-packages directory. Rather, some files that > exist in both levels, and changed between the two, are not updated by > install. So you wind up with a mixture of 0.96.x and 1.0 level files, which > is pretty confusing and subject to odd failures. > > Does anyone know if there is something we could do to prevent this > situation? I'm not very familiar with Python installation procedures. It > seems like it would be better, though, if our installer flat-out refused to > install over a pre-existing installation or offered to delete the > pre-existing install before continuing with the new install. What's the > norm for Python packages? > > Karen --~--~-~--~~~---~--~~ 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: Install over old level produces mutant [solved!]
Karen Tracey wrote: > We've had at least three people run into a problem (#9090) after > installing 1.0 over an old level. Now, we do document that before > installing you should remove any old level. But I find the results > when you don't rather odd. It's not just old files renamed/deleted in > the new level that wind up being 'leftover' in the site-packages > directory. Rather, some files that exist in both levels, and changed > between the two, are not updated by install. So you wind up with a > mixture of 0.96.x and 1.0 level files, which is pretty confusing and > subject to odd failures. > > Does anyone know if there is something we could do to prevent this > situation? I'm not very familiar with Python installation > procedures. It seems like it would be better, though, if our > installer flat-out refused to install over a pre-existing installation > or offered to delete the pre-existing install before continuing with > the new install. What's the norm for Python packages? > > Karen > I suspect what's happening is that the install keeps the distribution dates on the .py files, but that the people who see the problems have installed (or at least recompiled) the older versions more recently, so the interpreter doesn't require an overwrite of the 0.96 files. I've just done an install of 1.0 on my Python 2.6 alpha2 distribution and I see, for example, that .../django/views/static.py is dated 12/17/2007. In this case there wasn't a previous installation, so I can't verify that the compilation won't take place if there's an existing .pyc file. However I *did* verify that a clean re-install (after deletion of the appropriate build subdirectories) did *not* change the creation time of the .py file. So the answer is to put another step in the build process that touches all files before bundling them up for distribution. Obviously this is best done outside the version control system. regards Steve --~--~-~--~~~---~--~~ 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: Install over old level produces mutant [solved!]
Steve Holden wrote: [...] > I've just done an install of 1.0 on my Python 2.6 alpha2 distribution > and I see, for example, that .../django/views/static.py is dated > 12/17/2007. In this case there wasn't a previous installation, so I > can't verify that the compilation won't take place if there's an > existing .pyc file. However I *did* verify that a clean re-install > (after deletion of the appropriate build subdirectories) did *not* > change the creation time of the .py file. Sorry, that should have been ".pyc file". > regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ --~--~-~--~~~---~--~~ 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: Admin area and user permissions bug?
Martin Diers wrote: > This is not a bug. It is how the permissions system works. So far as > the Admin goes, it is model granular, not row granular or field > granular, meaning that if you grant a user full access to the User > object, as you did, they can do anything to that table, including > change permission levels. The permissions system does not have the > concept of a hierarchy of permissions. > > Suggest you read the docs, and direct any questions to the users list: > http://docs.djangoproject.com/en/dev/topics/auth/ > Thanks for the reply. I filed a bug report and got pretty much the same answer. I understand there is no support for granular permissions at the moment and this is something post-1.0. Though thinking logically most people will consider this a bug because by giving other users permission to add/edit other users you implicitly make them a superuser which means they also gain access to other area that should be restricted. I don't want to start a fight here and I am happy to wait for the granular permissions system to be set in place. Btw, I posted this in the user list initially but was ignored, hence this list is the next best thing! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
RFC: django.template refactoring (#7806)
Why should django.template be refactored? Filter and Variable parsing is inconsistent. Many ad hoc parsers in defaulttags are fragile. Whitespace handling is ungraceful. The patch provided in #7806[1] splits __init__.py into separate modules[2] and introduces a TokenStream class that allows parsing of literals, vars (called lookups) and filter expressions. Here's how it would work: @register.tag @uses_token_stream def mytag(parser, bits): expr = bits.parse_expression(required=True) return MyNode(expr) `uses_token_stream` replaces the Token argument to the parser function with a TokenStream object. If the token is not fully parsed, a TemplateSyntaxError is raised. For better examples, have a look at the patched version of `django.template.defaulttags`. TokenStream API (first stab) ``def __init__(self, parser, source)`` parser: a django.template.compiler.Parser instance source: a string or a django.template.compiler.Token instance TokenStream tokenizes its source into "string_literal", "numeric_literal", "char", and "name" tokens, stored in self.tokens as (type, lexeme) pairs. Whitespace will be discarded. You can "read" tokens via the following methods, the current position in self.tokens is maintained in self.offset. A "char" token is a single character in ':|=,;<>!?%&@"\'/()[]{}`*+-'. A name is any sequence of characters that does contain neither "char" characters nor whitespace and is not a string or numeric literal. >>> TokenStream(parser, r'"quoted\" string"|filter:3.14 as name').tokens [('string_literal', '"quoted\\" string"'), ('char', '|'), ('name', 'filter'), ('char', ':'), ('numeric_literal', '3.14'), ('name', 'as'), ('name', 'name')] >>> TokenStream(parser, r' "quoted\" string" | filter : 3.14 as name').tokens [('string_literal', '"quoted\\" string"'), ('char', '|'), ('name', 'filter'), ('char', ':'), ('numeric_literal', '3.14'), ('name', 'as'), ('name', 'name')] Low level API - ``def pop(self)`` Returns a pair (tokentype, lexeme) and offset+=1; tokentype is one of "string_literal", "numeric_literal", "char", "name". ``def pop_lexem(self, match)`` Returns True and offset+=1 if the next token's lexeme equals `match`. Returns False otherwise. ``def pop_name(self)`` Returns the next token's lexeme and offset+=1 if its tokentype is "name". Returns None otherwise. ``def pushback(self)`` offset-=1 High level API -- These methods raise TokenSyntaxError and leave offset untouched if the expected result cannot be parsed. Each accepts a boolean required=False kwarg which turns TokenSyntaxErrors into TemplateSyntaxErrors if True. ``def parse_string(self, bare=False)`` Returns the value of the following string literal. If bare=True, unquoted strings will be accepted. ``def parse_int(self)`` Returns the value of the following numeric literal, if it is an int. ``def parse_value(self)`` Returns an Expression that evaluates the following literal, variable or translated value. ``def parse_expression(self)`` Returns an Expression that evaluates the following value or filterexpression. ``def parse_expression_list(self, minimum=0, maximum=None, count=None)`` Returns a list `e` of expressions; minimum <= len(e) <= maximum. count=n is a shortcut for minimum=maximum=n. I'm unhappy with the naming of TokenStream and uses_token_stream (using_token_stream?). And I just noticed the english spelling of lexeme has a trailing "e". [1] http://code.djangoproject.com/ticket/7806 [2] See [1] for details. Yes, this is orthogonal to the concern of the ticket. I gave up splitting the patch when I stumbled upon the first circular dependency issue - a half-assed effort - and decided it's not worth it. --~--~-~--~~~---~--~~ 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: Proposal: installmedia command - A story for distributing media with apps
On Tue, Sep 16, 2008 at 9:56 PM, Brian Beck <[EMAIL PROTECTED]> wrote: > > Distributing media with apps could be a lot easier. Currently this > requires copying or linking files manually (possibly each time the app > is updated), and this encourages developers to put CSS and JavaScript > inline in their templates. I propose a management command to make > this easier: > > $ python manage.py installmedia appname [appname ...] I have already implemented this in our in-house django-based framework. If interested, I can provide it. As you said, it really does make things very simple. Regards Rajeev J Sebastian --~--~-~--~~~---~--~~ 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: Proposal: installmedia command - A story for distributing media with apps
> I have already implemented this in our in-house django-based > framework. If interested, I can provide it. As you said, it really > does make things very simple. > Please do, I'd be interested even if it doesn't make it to the trunk. Erik --~--~-~--~~~---~--~~ 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: Proposal: user-friendly API for multi-database support
On Sep 10, 12:53 pm, Simon Willison <[EMAIL PROTECTED]> wrote: > For those who weren't at DjangoCon, here's the state of play with > regards to multi-db support: Django actually supports multiple > database connections right now: the Query class (in django/db/models/ > sql/query.py) accepts a connection argument to its constructor, and > the QuerySet class (django/db/models/query.py) can be passed an > optional Query instance - if you don't pass it one, it will create a > Query that uses the default django.db.connection. Hmm.. so to the first layer of the onion, that statement is true... But now, how does one get a custom connection? Altnernate connection info needs to be able to be passed in to the DatabaseWrapper constructors, so that you can call them with different database information; and then when BaseDatabaseWrapper.cursor() calls _cursor() it should pass in a *copy* of the global settings overridden with anything passed in as kwargs to BaseDatabaseWrapper.__init__() (which is already saved in self.options) . That is, instead of def cursor(self): from django.conf import settings cursor = self._cursor(settings) if settings.DEBUG: return self.make_debug_cursor(cursor) return cursor We should do: def cursor(self): from django.conf import settings mysettings = settings.copy().update(self.options) cursor = self._cursor(mysettings) if settings.DEBUG: return self.make_debug_cursor(cursor) return cursor And then we can do something like from django.db.backends.mysql.base import DatabaseWrapper as OracleDatabaseWrapper myconnection = OracleDatabaseWrapper(DATABASE_HOST='somwhere.example.com', DATABASE_USER='tiger', ... ) and then you could use myconnection in your Manager subclass, etc. Anyhow, that seems to me like it is a stab at addressing the simple "some model classes talk to a different database" approach. One could make a ManagerWithAlternateConnection class that is a subclass of Manager and takes a database connection as a parameter and does that. --~--~-~--~~~---~--~~ 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: RFC: django.template refactoring (#7806)
On Sep 16, 2:36 pm, Johannes Dollinger <[EMAIL PROTECTED]> wrote: > Why should django.template be refactored? Filter and Variable parsing > is inconsistent. Many ad hoc parsers in defaulttags are fragile. > Whitespace handling is ungraceful. > > The patch provided in #7806[1] splits __init__.py into separate > modules[2] and introduces a TokenStream class that allows parsing of > literals, vars (called lookups) and filter expressions. Regardless of how it happens, I did notice when writing a patch for #9093 that django.template really could use some refactoring. +1 --~--~-~--~~~---~--~~ 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: [Fwd: Documentation: Google-foo lost]
On Mon, Sep 15, 2008 at 10:29 PM, Russell Keith-Magee < [EMAIL PROTECTED]> wrote: > > It would be > fantastic if such a mapping existed, and I don't think you'd get any > objections from the core developers if such a mapping were to > magically materialize. > poof! I took a shot at finding redirects for the top 50 results on google for site:djangoproject.com/documentation/ that weren't 0.9x specific. Most were fairly obvious, so I dropped them into a text file that's formatted similar to http://code.djangoproject.com/browser/djangoproject.com/django_website/apps/docs/urls.py. There's two that I wasn't sure about: /documentation/models/many_to_one/ : http://docs.djangoproject.com/en/dev/topics/db/models/ OR http://docs.djangoproject.com/en/dev/topics/db/queries/ /documentation/admin_css/: http://docs.djangoproject.com/en/dev/obsolete/admin-css/ OR http://docs.djangoproject.com/en/dev/faq/admin/ Hope it's useful! Don --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- (r'^contenttypes/$', HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/ref/contrib/contenttypes/')), (r'^pagination/$', HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/pagination/')), (r'^i18n/$', HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/i18n/')), (r'^shortcuts/$', HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/http/shortcuts/')), (r'^distributions/$', HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/misc/distributions/')), (r'^form_wizard/$', HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/ref/contrib/formtools/form-wizard/')), (r'^tutorial02/$', HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/intro/tutorial02/')), (r'^testing/$', HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/testing/')), (r'^databases/$', HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/ref/databases/')), (r'^outputting_pdf/$', HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/howto/outputting-pdf/')), (r'^files/$', HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/files/')), (r'^tutorial04/$', HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/intro/tutorial04/')), (r'^modelforms/$', HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/forms/modelforms/')), (r'^unicode/$', HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/ref/unicode/')), (r'^authentication/$', HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/auth/')), (r'^fastcgi/$', HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/howto/deployment/fastcgi/')), (r'^transactions/$', HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/db/transactions/')), (r'^api_stability/$', HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/misc/api-stability/')), (r'^upload_handling/$', HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/http/file-uploads/')), (r'^faq/$', HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/faq/')), (r'^serialization/$', HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/serialization/')), (r'^models/$', HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/db/models/')), (r'^redirects/$', HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/ref/contrib/redirects/')), (r'^databrowse/$', HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/ref/contrib/databrowse/')), (r'^tutorial03/$', Http
Re: [Fwd: Documentation: Google-foo lost]
On Tue, Sep 16, 2008 at 2:20 PM, Don Spaulding <[EMAIL PROTECTED]>wrote: > > Hope it's useful! > and of course it isn't. I forgot my lambdas. Doh! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- (r'^contenttypes/$', lambda r: HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/ref/contrib/contenttypes/')), (r'^pagination/$', lambda r: HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/pagination/')), (r'^i18n/$', lambda r: HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/i18n/')), (r'^shortcuts/$', lambda r: HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/http/shortcuts/')), (r'^distributions/$', lambda r: HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/misc/distributions/')), (r'^form_wizard/$',lambda r: HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/ref/contrib/formtools/form-wizard/')), (r'^tutorial02/$', lambda r: HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/intro/tutorial02/')), (r'^testing/$',lambda r: HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/testing/')), (r'^databases/$', lambda r: HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/ref/databases/')), (r'^outputting_pdf/$', lambda r: HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/howto/outputting-pdf/')), (r'^files/$', lambda r: HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/files/')), (r'^tutorial04/$', lambda r: HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/intro/tutorial04/')), (r'^modelforms/$', lambda r: HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/forms/modelforms/')), (r'^unicode/$',lambda r: HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/ref/unicode/')), (r'^authentication/$', lambda r: HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/auth/')), (r'^fastcgi/$',lambda r: HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/howto/deployment/fastcgi/')), (r'^transactions/$', lambda r: HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/db/transactions/')), (r'^api_stability/$', lambda r: HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/misc/api-stability/')), (r'^upload_handling/$',lambda r: HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/http/file-uploads/')), (r'^faq/$',lambda r: HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/faq/')), (r'^serialization/$', lambda r: HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/serialization/')), (r'^models/$', lambda r: HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/topics/db/models/')), (r'^redirects/$', lambda r: HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/ref/contrib/redirects/')), (r'^databrowse/$', lambda r: HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/ref/contrib/databrowse/')), (r'^tutorial03/$', lambda r: HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/intro/tutorial03/')), (r'^tutorial01/$', lambda r: HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/intro/tutorial01/')), (r'^legacy_databases/$', lambda r: HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/howto/legacy-databases/')), (r'^outputting_csv/$', lambda r: HttpResponsePermanentRedirect('http://docs.djangoproject.com/en/dev/howto/o
Re: Composite Fields
I think that will work Malcom. One thing we'll need to deal with, is .name, .attname, etc on these. It should act the same way on the pk as it does on the multi-column field (because after all, this will be just a wrapper). Right now .pks is just an alias for .pk.as_tuple or something. I had it throwing errors if you tried accessing .pk.name if there were multiple fields in it, as name is the field name, and the field name becomes multiple. I will post up what I have done later tonight. On Sep 16, 9:36 am, Rock <[EMAIL PROTECTED]> wrote: > Malcolm, > > I strongly concur with the proposed API. It looks like it can be used > to implement future RangeHash partitioning support. Consider: > > I have a model to be partitioned that has an IntegerField that will > become the range partitioning value: > > week = models.IntegerField() # 1 to 53 depending on the week of > creation > > The hash partitioning value is a field that works precisely like "id": > > hash_id = models.IntegerField( auto_everything=True ) # (I made > "auto_everything" up as I am not sure precisely what parameters I need > to set in order to make this happen.) > > Now I can create my RangeHash partitioning primary key with a > compositeField: > > range_hash = models.CompositeField( hash_id, week, primary_key=True ) > > What I am doing today for my partitioned models is to use the > automatically generated "id" field, but that looks dicey with the > CompositeField since you can't do this: > > range_hash = models.CompositeField( id, week, primaryKey=True ) > > since "id" doesn't exist yet and, by designating this CompositeField > as the primary key, id won't be generated. Rather than try to special > case this situation, ensuring that I can create a field that works > precisely like "id" by hand and then using that seems to be the way to > go. > > Rock --~--~-~--~~~---~--~~ 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: Proposal: installmedia command - A story for distributing media with apps
Brian Beck wrote: > Distributing media with apps could be a lot easier. Currently this > requires copying or linking files manually (possibly each time the app > is updated), and this encourages developers to put CSS and JavaScript > inline in their templates. I propose a management command to make > this easier: > > $ python manage.py installmedia appname [appname ...] Oh, yes! I was trying to invent some way to distribute media (apart from documenting copying it in a README) but with no luck. Yet your solution is so simple and beautiful! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
incorrect field type for object_pk in contrib.comments?
Looking at contrib.comments admin, i noted that the Object ID input is a textarea. i thought that was strange, since i expceted an input (type="text"). Turns out, in the model, this is a TextField, rather than a CharField. http://code.djangoproject.com/browser/django/trunk/django/contrib/comments/models.py#L23 Is there a reason this should be a TextField, or is that a mistake? --~--~-~--~~~---~--~~ 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: Proposal: installmedia command - A story for distributing media with apps
On Tue, Sep 16, 2008 at 11:26 AM, Brian Beck <[EMAIL PROTECTED]> wrote: > > $ python manage.py installmedia appname [appname ...] > > The command is "dumb.".. Could it be a little smarter, and in the absence of specific apps, iterate over all INSTALLED_APPS, and install their media automagically? --~--~-~--~~~---~--~~ 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: Install over old level produces mutant
Karen Tracey wrote: > We've had at least three people run into a problem (#9090) after > installing 1.0 over an old level. Now, we do document that before > installing you should remove any old level. But I find the results when > you don't rather odd. It's not just old files renamed/deleted in the new > level that wind up being 'leftover' in the site-packages directory. > Rather, some files that exist in both levels, and changed between the > two, are not updated by install. So you wind up with a mixture of > 0.96.x and 1.0 level files, which is pretty confusing and subject to odd > failures. does that apply to PY files, or is it just that you may have PYC files from 0.96.x but PY files from 1.0? (Python only looks at the timestamp when deciding whether to recompile a PY file, so if your PYC files for 0.96.x were created later than the corresponding 1.0 file, Python will pick up the wrong file). is the installer you're referring to here "setup.py", or something else? --~--~-~--~~~---~--~~ 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: Install over old level produces mutant
Fredrik Lundh wrote: > Karen Tracey wrote: > > >> We've had at least three people run into a problem (#9090) after >> installing 1.0 over an old level. Now, we do document that before >> installing you should remove any old level. But I find the results when >> you don't rather odd. It's not just old files renamed/deleted in the new >> level that wind up being 'leftover' in the site-packages directory. >> Rather, some files that exist in both levels, and changed between the >> two, are not updated by install. So you wind up with a mixture of >> 0.96.x and 1.0 level files, which is pretty confusing and subject to odd >> failures. >> > > does that apply to PY files, or is it just that you may have PYC files > from 0.96.x but PY files from 1.0? (Python only looks at the timestamp > when deciding whether to recompile a PY file, so if your PYC files for > 0.96.x were created later than the corresponding 1.0 file, Python will > pick up the wrong file). > > is the installer you're referring to here "setup.py", or something else? > > See ticket #9112 for a purported explanation. regards Steve --~--~-~--~~~---~--~~ 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: incorrect field type for object_pk in contrib.comments?
It's intentional, usually you see an object_pk as an integer field, however that means it won't work with any field with a custom primary key, specifically those with string type pks. And a textfield offers the flexibility to work with all of those. On Sep 16, 3:42 pm, smcoll <[EMAIL PROTECTED]> wrote: > Looking at contrib.comments admin, i noted that the Object ID input is > a textarea. i thought that was strange, since i expceted an input > (type="text"). Turns out, in the model, this is a TextField, rather > than a CharField. > http://code.djangoproject.com/browser/django/trunk/django/contrib/com... > Is there a reason this should be a TextField, or is that a mistake? --~--~-~--~~~---~--~~ 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: Install over old level produces mutant
On Tue, Sep 16, 2008 at 5:23 PM, Steve Holden <[EMAIL PROTECTED]> wrote: > > Fredrik Lundh wrote: > > Karen Tracey wrote: > > > > > >> We've had at least three people run into a problem (#9090) after > >> installing 1.0 over an old level. Now, we do document that before > >> installing you should remove any old level. But I find the results when > >> you don't rather odd. It's not just old files renamed/deleted in the new > >> level that wind up being 'leftover' in the site-packages directory. > >> Rather, some files that exist in both levels, and changed between the > >> two, are not updated by install. So you wind up with a mixture of > >> 0.96.x and 1.0 level files, which is pretty confusing and subject to odd > >> failures. > >> > > > > does that apply to PY files, or is it just that you may have PYC files > > from 0.96.x but PY files from 1.0? (Python only looks at the timestamp > > when deciding whether to recompile a PY file, so if your PYC files for > > 0.96.x were created later than the corresponding 1.0 file, Python will > > pick up the wrong file). > > > > is the installer you're referring to here "setup.py", or something else? > > > > > See ticket #9112 for a purported explanation. > > I do not believe the description/explanation in that ticket is correct. It says the new .py files will be copied but .pyc files will not be created, which is not what I have observed. What I have seen is that new .py files are not copied at all. The tree is left with a mixture of old and new .py files. (And to answer Fredrik's question yes, I'm talking about 'setup.py install'.) It does seem to have been caused by inconsistent file dating during the release process over time. One problematic file is django/utils/dates.py. This file was last modified in SVN on 7/4/2007 at 8:11AM, and that is the date/time on the file when extracted from the 1.0 release tar file. However, going back to the 0.96.2 tarball, the date on its django/utils/dates.py file is 10/29/2007. I'm not sure where that date came from. 0.96.2 was announced on django-announce on 5/14/2008, so it's not when 0.96.2 came out. The actual revision level for the file is [2912], which was checked in on 5/16/06. And there's the problem -- it's an earlier level of the file than what's in 1.0, but it appears based on the date to be more recent. Going back to the 0.96.1 tarball (yes I'm a packrat), the date on its django/utils/dates.py is 10/26/2007, which is the same date as 0.96.1 was announced. So the problem seems to be that some of the older tar files for releases used tar file creation date (or ? since I'm not sure about the 0.96.2 one) for files contained in the release, while 1.0 somehow put last-modified in SVN dates on the files (I didn't know SVN would even do that, actually). Seems it would be safer to use tarfile creation date always. That still leaves potential problems for people doing install-overs. Old files that have been renamed/deleted won't get deleted, and that can cause problems. Even though we say you should first delete old levels, and even if the release process is adjusted to fix up the dates, I think it would be a good idea to refuse to install if an old level is detected. Karen --~--~-~--~~~---~--~~ 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: Proposal: installmedia command - A story for distributing media with apps
On Sep 17, 7:09 am, "Don Spaulding" <[EMAIL PROTECTED]> wrote: > On Tue, Sep 16, 2008 at 11:26 AM, Brian Beck <[EMAIL PROTECTED]> wrote: > > > $ python manage.py installmedia appname [appname ...] > > > The command is "dumb.".. > > Could it be a little smarter, and in the absence of specific apps, iterate > over all INSTALLED_APPS, and install their media automagically? +1 for some sort of media.autodiscover(). It would have to be optional though, as that might break backwards- compatibility. Also, there's an issue about the way files are served. For example, in my projects I make Apache serve 'admin_media' files independently. What would be an approach to make that serving configuration happen for custom apps? --~--~-~--~~~---~--~~ 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: Proposal: installmedia command - A story for distributing media with apps
On Sep 16, 6:29 pm, Julien Phalip <[EMAIL PROTECTED]> wrote: > > Could it be a little smarter, and in the absence of specific apps, iterate > > over all INSTALLED_APPS, and install their media automagically? > > +1 for some sort of media.autodiscover(). > It would have to be optional though, as that might break backwards- > compatibility. I think he meant making "python manage.py installmedia" (no app names provided) install media for all INSTALLED_APPS, not something that will happen without running any commands -- so no backwards- compatibility will be affected. And I agree with Don's idea. > Also, there's an issue about the way files are served. For example, in > my projects I make Apache serve 'admin_media' files independently. > What would be an approach to make that serving configuration happen > for custom apps? Serving is totally orthogonal -- everyone is already serving up MEDIA_ROOT in their projects somehow anyway, and this just copies files to MEDIA_ROOT. --~--~-~--~~~---~--~~ 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: Proposal: installmedia command - A story for distributing media with apps
On Sep 16, 6:45 pm, Brian Beck <[EMAIL PROTECTED]> wrote: > Serving is totally orthogonal -- everyone is already serving up > MEDIA_ROOT in their projects somehow anyway, and this just copies > files to MEDIA_ROOT. Sorry, I guess that's not totally true -- everyone who uses more than just the admin app has set up static file serving for MEDIA_ROOT. --~--~-~--~~~---~--~~ 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: I want a pony: Django Cheeseshop
On Tue, 2008-09-16 at 05:06 -0700, mrts wrote: > Both of these arguments are valid, but will not help to resolve the > problem: smooth experience in distributing and using pluggable > applications and some order in the current chaos. > > On Sep 16, 2:10 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> > wrote: > > On Tue, 2008-09-16 at 00:16 -0700, mrts wrote: > > > Let me try to wrap this up: > > > > > * there seems to be a general consensus that amending setuptools to > > > create Django-specific extensions is not required > > > * a separate repository is not required, apps should be published to > > > PyPi Famework :: Django category but a central site that tracks the > > > apps there to further classify, rate and enhance them would be useful > > > (like djangoplugables.com) > > > * app naming and namespace issues should be resolved (should all apps > > > have a django-prefix, the de facto standard? should they live in > > > django.apps namespace?) > > > > As others have pointed out, this isn't necessary and would be bad > > practice. Everybody should feel free to use whatever namespace they like > > to avoid clashes and so that we avoid lowering the quality of the Django > > brand (as soon as somebody installs a few low-quality "packages" and > > they misbehave in any way, it's going to be "Django is a pile of > > rubbish" because it's all coming from the Django namespace). > > Lets not use the `django` namespace then -- `djangoapps`, `djc` (as > django community, mimicking z3c), whatnot. Do you think the > introspection and media arguments are irrelevant? These would provide > practical gain apart from the general feel of coherence I'm trying to > advocate. > > As for coherence: standardized toplevel namespace would help to > discern at a glance which bits of a project are Django-related and > which are not, just by looking at the imports in a .py. Everybody > should feel free to use whatever namespace or namespace hierarchy they > like *under* that namespace. > > As for the brand, the existing practice for naming packaged Django > apps is to use the 'django-' prefix anyway. Should that be discouraged > (which doesn't sound good to me)? > > > > * dependencies should be handled with setuptools facilities > > > > As an option, only. This can't be a requirement, since setuptools will > > often download random stuff from the internet, doesn't support signed > > packages as a rule, doesn't integrate well with existing packaging > > systems such as rpm and apt (which includes the fact that it downloads > > random extra stuff without asking) and doesn't make it easy to validate > > the source code at a later date. In other words, it's insecure by design > > and therefore inappropriate for large system installs. People might be > > happy to use it on their laptops or whatever, but a lot of system > > administrators should rightly feel very nervous about using setuptools. > > apt and rpm don't mix with project-specific packages and versioning > (virtualenv/buildout). It is just not feasible (or even possible if > something is built against django-0.96 and something else against > django-1.0) Don't tell that to my laptop and some systems I admin which have completely parallel installation of Python 2.4 and everything else I need to do Plone work, all managed by rpms, then. They don't like being told that what they're doing is apparently impossible. :-) Yes, it doesn't work trivially with virtualenv, but so what? It's not part of the use-case of virtualenv and buildout which are targeted at an different audience and use-case. Sandboxed development environments have been in use for years and they work very well when you're developing. They're also not how you deploy things to dozens of machines at once in a very large installation. At that point you use the sandboxed environment to build packages that work with the system they're being installed on and which install in parallel. Not every sandbox environment is designed to do that and that is fine. > to dump everything into the global package space if you > have diverse projects hosted on a single server. > > setuptools is a necessary evil for the agile developer who frequently > tracks updates for the bits he relies upon. Hopefully it will be > improved (the clamor around it is ever-ongoing), but unless we want to > do it ourselves, we have to accept the state of things. Wow. You just said we should entirely ditch security because it isn't convenient. That's exactly the attitude that has made Microsoft the laughing stock of the professional IT community for the last 15 years. If my original mail had said "nobody should ever use setup tools" or anything like that, you reply might be valid. Go back and read it. I said "optional", not "forbidden". There are multiple audiences here. If Django ever had a hard dependency on setuptools for using third-party packages it would make it very difficult for system administrators to use Django because of the large le
Re: Special case: DateTimeField and SplitDateTimeWidget
I've just had another thought. With `SplitDateTimeWidget` validation coupled to `DateTimeField`, it's no longer easy to subclass `DateTimeField` for use with your own `MultiValueWidget`. When you call `super` for the DateTimeField validation, it will run `DateTimeField.clean` which will return an invalid error if your own widget doesn't return date and time in two parts. The user would have to re-write the entire `DateTimeField.clean` method, but *without* the `SplitDateTimeWidget` validation. Even more so now I think this validation should be de-coupled from `DateTimeField`. --~--~-~--~~~---~--~~ 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: Proposal: installmedia command - A story for distributing media with apps
On Sep 17, 8:49 am, Brian Beck <[EMAIL PROTECTED]> wrote: > On Sep 16, 6:45 pm, Brian Beck <[EMAIL PROTECTED]> wrote: > > > Serving is totally orthogonal -- everyone is already serving up > > MEDIA_ROOT in their projects somehow anyway, and this just copies > > files to MEDIA_ROOT. > > Sorry, I guess that's not totally true -- everyone who uses more than > just the admin app has set up static file serving for MEDIA_ROOT. I really like the idea. However, I think there should also be a way to configure it to not copy to MEDIA_ROOT but to somewhere else. It would also be good to get that deployment system play nicely with custom file storage (if you're hosting your media on S3 for example). Also, instead of just copying the media files, it should also do some cleanup. Say, if you're tracking trunk for a given app, when you SVN update that app you want stale media files to be removed. Just some thoughts. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
bug in forms
Hi, I find a bug in forms of django, i know i have report a ticket but the bug is very small, in the file django/forms/models.py in line 236: if name in self.cleaned_data and f.unique and not is_null_pk: and in the doc, the variable self.cleaned is now self.clean_data thanks -- Diego Andrés Sanabria Ingeniería de Sistemas Universidad Distrital blog trágico mágico cómico musical: http://diegueus9.blogspot.com blog geek: http://pyautoservicio.blogspot.com cel 3015290609 http://www.el-directorio.org/Diegueus9 El sitio de linux y el Software Libre en Colombia "Hay pecados cuya fascinación está más en el recuerdo que en la comisión de ellos." Oscar Wilde --~--~-~--~~~---~--~~ 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: bug in forms
On Tue, Sep 16, 2008 at 4:27 PM, Diego Andrés Sanabria Martin (diegueus9) <[EMAIL PROTECTED]> wrote: > if name in self.cleaned_data and f.unique and not is_null_pk: > and in the doc, the variable self.cleaned is now self.clean_data You are incorrect. The variable was clean_data in 0.96 but changed to cleaned_data shortly after to avoid conflicts with validation functions for a field named "data" - you are reading old examples and/or docs. -- Collin Grady --~--~-~--~~~---~--~~ 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: Proposal: installmedia command - A story for distributing media with apps
On Sep 16, 7:22 pm, Julien Phalip <[EMAIL PROTECTED]> wrote: > I really like the idea. However, I think there should also be a way to > configure it to not copy to MEDIA_ROOT but to somewhere else. Sure - a --destination flag, defaulting to MEDIA_ROOT, would work. > Also, instead of just copying the media files, it should also do some > cleanup. Say, if you're tracking trunk for a given app, when you SVN > update that app you want stale media files to be removed. This is getting into package management system territory ;) -- this problem is mostly solved by linking a directory instead of copying all the files, which I think should be the default behavior (linking, not copying). --~--~-~--~~~---~--~~ 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: Proposal: installmedia command - A story for distributing media with apps
Not sure if you guys are aware, but this seems a very likely candidate for django-exensions which extends manage.py like functionality. http://code.google.com/p/django-command-extensions/ -justin On Tue, Sep 16, 2008 at 7:22 PM, Julien Phalip <[EMAIL PROTECTED]> wrote: > > On Sep 17, 8:49 am, Brian Beck <[EMAIL PROTECTED]> wrote: >> On Sep 16, 6:45 pm, Brian Beck <[EMAIL PROTECTED]> wrote: >> >> > Serving is totally orthogonal -- everyone is already serving up >> > MEDIA_ROOT in their projects somehow anyway, and this just copies >> > files to MEDIA_ROOT. >> >> Sorry, I guess that's not totally true -- everyone who uses more than >> just the admin app has set up static file serving for MEDIA_ROOT. > > I really like the idea. However, I think there should also be a way to > configure it to not copy to MEDIA_ROOT but to somewhere else. > > It would also be good to get that deployment system play nicely with > custom file storage (if you're hosting your media on S3 for example). > > Also, instead of just copying the media files, it should also do some > cleanup. Say, if you're tracking trunk for a given app, when you SVN > update that app you want stale media files to be removed. > > Just some thoughts. > > > -- Justin Lilly Web Developer/Designer http://justinlilly.com --~--~-~--~~~---~--~~ 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: bug in forms
i found this: Changed in Django 1.0: The cleaned_data attribute was called clean_data in earlier releases. in http://docs.djangoproject.com/en/dev/topics/forms/#topics-forms-index I make a mistake? On Tue, Sep 16, 2008 at 18:29, Collin Grady <[EMAIL PROTECTED]> wrote: > On Tue, Sep 16, 2008 at 4:27 PM, Diego Andrés Sanabria Martin > (diegueus9) <[EMAIL PROTECTED]> wrote: >> if name in self.cleaned_data and f.unique and not is_null_pk: >> and in the doc, the variable self.cleaned is now self.clean_data > > You are incorrect. The variable was clean_data in 0.96 but changed to > cleaned_data shortly after to avoid conflicts with validation > functions for a field named "data" - you are reading old examples > and/or docs. > > -- > Collin Grady > > > > -- Diego Andrés Sanabria Ingeniería de Sistemas Universidad Distrital blog trágico mágico cómico musical: http://diegueus9.blogspot.com blog geek: http://pyautoservicio.blogspot.com cel 3015290609 http://www.el-directorio.org/Diegueus9 El sitio de linux y el Software Libre en Colombia "Hay pecados cuya fascinación está más en el recuerdo que en la comisión de ellos." Oscar Wilde --~--~-~--~~~---~--~~ 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: bug in forms
On Tue, Sep 16, 2008 at 4:33 PM, Diego Andrés Sanabria Martin (diegueus9) <[EMAIL PROTECTED]> wrote: > i found this: > Changed in Django 1.0: The cleaned_data attribute was called > clean_data in earlier releases. > > in http://docs.djangoproject.com/en/dev/topics/forms/#topics-forms-index > > I make a mistake? That line also says what I said - it *used to be* clean_data in 0.96, but it *is* cleaned_data now. So if the line of code had clean_data, it would be wrong, but it has cleaned_data, so it is right. -- Collin Grady --~--~-~--~~~---~--~~ 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: RFC: django.template refactoring (#7806)
On Tue, 2008-09-16 at 20:36 +0200, Johannes Dollinger wrote: > Why should django.template be refactored? Filter and Variable parsing > is inconsistent. Many ad hoc parsers in defaulttags are fragile. > Whitespace handling is ungraceful. > > The patch provided in #7806[1] splits __init__.py into separate > modules[2] and introduces a TokenStream class that allows parsing of > literals, vars (called lookups) and filter expressions. As was pointed out the first time you brought this up, keep in mind that there still need to be ways to manually control the lexing phase. Not every template tag has the same requirements there. Also, since the Variable class is part of the public API (we document how to write custom template tags), you need to preserve backwards compatibility. For example, anything written according to custom-template-tags.txt should continue to work unchanged. There are possibly some reasonable other methods in template/__init__.py that should continue to remain available as well. That being said, I'm completely in favour of a bit of shuffling in those files to make things easier to understand and fix a bunch of little inconsistencies. However, I'd encourage doing it in slightly smaller steps than the original patches I read so that we can see that backwards compatibility is maintained and do the smallest number of changes necessary to tidy things up. Basically, keep the refactoring and the feature/API addition portions distinct. For example, it's useful (and necessary) to make the Variable class be a lot more consistent with respect to also resolving the effect of apply filters to variables (right now, anything using Variable doesn't have filter effects applied, which was probably just an oversight originally). Helper methods that make it easy for the common cases to say "I expect three paramters matching the 'x y as z' pattern where x and z are strings and y must be an integer" would be very handy. This is where method like your parse_int and parse_string methods are additions that would be useful. Things like parse_expression is probably overkill for a high-level API, since resolving the effect of filters should really just be a natural part of Variable.resolve_context(). I'm not sure I see the use-case at the moment for parse_expression; perhaps you could elaborate with an example. Regards, Malcolm --~--~-~--~~~---~--~~ 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: Recursive inlines in admin?
Hey All, First off, I am a relatively new Django user, and certainly not a developer at this point, and most of this post is pure speculation. With that disclaimer, I'll share my situation and opinion: >From DoctorMO: > Well I've seen far more normalised models that don't match how simple > data entry people's minds expect the forms to be presented. Binding > them back together using in-lines is one method of having a complex > set of models editable as one entry form. This is exactly the problem that I am running into right at the moment. My data entry people will pitch a fit if I make them use the current setup, which would require at least two levels for my site, with very awkward transitions (save this object, go add a related object, search for the first object using a raw id lookup, then finally edit the related inlines). This is painful. But... >From Adrian: > This has come up a number of times over the years, and I still haven't > wrapped my head around why somebody would need this functionality... > Surely one could just use the "standard" admin for the third-level > objects, then use two-level inlines for the first- and second-level > objects? I started writing a long email about why I want this functionality, then changed my mind. Adrian's 'just use the standard admin' response would get me *very* close to what I want, with just a few enhancements. Here's how: I just watched to 'I want a pony' session from DjangoCon, and I noticed two points that fit this discussion: 1. Raw ids are 'too raw'. Let's do some sort of search/select instead of a drop down. 2. Databrowse is cool, but outdated. Databrowse integrated into Admin would kick ass. I'll add one more: 3. With the Admin refactor, it should be easy to create *both* an inline *and* a stand-alone admin object for the same model, and register both. I'm assuming you have a layout something like this (a simplified look at my database layout): A <-- B <-- [X, Y, Z] A is your main table, B has a few entries for each A, and X, Y and Z all point B. I *think* this will generalize pretty nicely, but I haven't thought my way through any really complicated relations yet. --- My proposal is this. The cool thing databrowse does is link between related objects. To get databrowse-like functionality with only a little work, do this: 1. Implement an option to search/select in place of raw ids or drop- down/select on the stand-alone admin. While I'm not much of a UI guy, it seems to me that I can already have most of the search functionality I need set up in the Admin site for my related object. So, keep the raw id idea, but display a string representation of the object instead of its id? 2. Create an Admin object for A, and inline B. Also create a stand- alone Admin object for B, and inline X, Y and Z. 3. If both inline and stand-alone Admin objects are registered for B, add links from one to the other. Text links would be fine, or a small go-to-this-object-arrow icon. 3a. If you don't register both admin objects, the link could instead go to a typical databrowse page to let you look at the related object, and what objects are related to it. This is not critical for this discussion, but it does seem to be an easy way to start integrating databrowse functionality into the admin. --- Now my workflow looks like this: Add an A, and add a B inline, save. Now link to my newly created B, and edit X, Y and Z objects inline, and save. And if I'm creating a B in the stand-alone admin, I can easily search for my related A, then navigate to that related object by clicking a link. This is the visual equivalent of the way that Django's query API works. This would mean I could train my users to save the first object, then follow a link. That's a pretty easy thing to do, and it is significantly less painful than the first workflow I described using the current admin setup. How hard would this actually be to accomplish? Are there any glaring errors in my thinking? Complex relationships that hose the whole idea? James --~--~-~--~~~---~--~~ 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: bug in forms
sorry, you have reason, my english is bad and i am tired, but i have this error: >>> form.clean() Traceback (most recent call last): File "", line 1, in ? File "/home/felipecastel/django1.0_src/django/forms/models.py", line 208, in clean self.validate_unique() File "/home/felipecastel/django1.0_src/django/forms/models.py", line 236, in validate_unique if name in self.cleaned_data and f.unique and not is_null_pk: AttributeError: 'IdeaForm' object has no attribute 'cleaned_data' >>> and i read the doc over and over again and i cant use the forms. On Tue, Sep 16, 2008 at 18:35, Collin Grady <[EMAIL PROTECTED]> wrote: > On Tue, Sep 16, 2008 at 4:33 PM, Diego Andrés Sanabria Martin > (diegueus9) <[EMAIL PROTECTED]> wrote: >> i found this: >> Changed in Django 1.0: The cleaned_data attribute was called >> clean_data in earlier releases. >> >> in http://docs.djangoproject.com/en/dev/topics/forms/#topics-forms-index >> >> I make a mistake? > > That line also says what I said - it *used to be* clean_data in 0.96, > but it *is* cleaned_data now. > > So if the line of code had clean_data, it would be wrong, but it has > cleaned_data, so it is right. > > -- > Collin Grady > > > > -- Diego Andrés Sanabria Ingeniería de Sistemas Universidad Distrital blog trágico mágico cómico musical: http://diegueus9.blogspot.com blog geek: http://pyautoservicio.blogspot.com cel 3015290609 http://www.el-directorio.org/Diegueus9 El sitio de linux y el Software Libre en Colombia "Hay pecados cuya fascinación está más en el recuerdo que en la comisión de ellos." Oscar Wilde --~--~-~--~~~---~--~~ 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: bug in forms
On Tue, Sep 16, 2008 at 7:35 PM, Collin Grady <[EMAIL PROTECTED]>wrote: > On Tue, Sep 16, 2008 at 4:33 PM, Diego Andrés Sanabria Martin > (diegueus9) <[EMAIL PROTECTED]> wrote: > > i found this: > > Changed in Django 1.0: The cleaned_data attribute was called > > clean_data in earlier releases. > > > > in http://docs.djangoproject.com/en/dev/topics/forms/#topics-forms-index > > > > I make a mistake? > > That line also says what I said - it *used to be* clean_data in 0.96, > but it *is* cleaned_data now. > > So if the line of code had clean_data, it would be wrong, but it has > cleaned_data, so it is right. > > -- > Collin Grady > > Perhaps the ticket should be opened to correct the passive (and therefore, more difficult to translate) voice in that sentence? --~--~-~--~~~---~--~~ 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: Composite Fields
On Tue, 2008-09-16 at 13:37 -0700, David Cramer wrote: > I think that will work Malcom. One thing we'll need to deal with, > is .name, .attname, etc on these. It should act the same way on the pk > as it does on the multi-column field (because after all, this will be > just a wrapper). Right now .pks is just an alias for .pk.as_tuple or > something. I had it throwing errors if you tried accessing .pk.name if > there were multiple fields in it, as name is the field name, and the > field name becomes multiple. The name attribute can return a tuple for CompositeFields. I've actually added a multicolumn attribute to the Field class so that one isn't stuck have to do isinstance() calls all the time; we can key off field.multicolumn (True or False), although I've got a fixme to think about calling that something less fiddly to type and less database-specific. Once we start treating them like proper fields that can have sequence values, I think it all falls intro place fairly easily. Regards, Malcolm --~--~-~--~~~---~--~~ 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: RFC: django.template refactoring (#7806)
On Sep 16, 7:36 pm, Johannes Dollinger <[EMAIL PROTECTED]> wrote: > @register.tag > @uses_token_stream > def mytag(parser, bits): > expr = bits.parse_expression(required=True) > return MyNode(expr) > > `uses_token_stream` replaces the Token argument to the parser > function with a TokenStream object. I'm completely in favour of some refactoring in django.template, but I'm not at all keen on that decorator syntax. Nested decorators get ugly quickly in my opinion, especially considering our need to keep supporting Python 2.3 syntax. Would @register.tag(token_stream=True) work instead, or am I missing something? Cheers, Simon --~--~-~--~~~---~--~~ 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: Proposal: app objects
I started working on a patch 6 months ago to implement App objects, but unfortunately never got to finish it because at the time I was swamped at work. Because of the all the work which has happened on trunk the code is pretty much useless. > The following can be addressed with app objects. > > 1. Allow multiple instances of an app object to exist Can you explain how this can be achieved (in regards to API)? I am currently can't figure out a clean solution or a use case which would require two installations of the same application. For example, someone for some reason wants to django.contrib.comments more than once, so they add to entries to the settings.py INSTALLED_APPS tuple. INSTALLED_APPS = (App('django.contrib.comments', name='comments'), App('django.contrib.comments', name='comments2', db_prefix='comments2')) syncdb works, and the two apps are installed. All is well. But for you to make use of the two applications, all views must become application aware. Does the urlpatterns take into account an App instance? urlpatterns = patterns('', url(r'^comments/', include('django.contrib.comments.urls'), app=get_app('comments2')), ) Does it still require the view to somehow check the application instance? For example a simple view; def my_view(request): comments = Comment.objects.all() render_to_response("comments/template.html", {"comments": comments}) How does the view know which app it is? Is it 'comments' or 'comments2'? Or am I completely confused to what this requested feature is trying to achieve? --~--~-~--~~~---~--~~ 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: bug in forms
On Tue, Sep 16, 2008 at 4:40 PM, Diego Andrés Sanabria Martin (diegueus9) <[EMAIL PROTECTED]> wrote: > sorry, you have reason, my english is bad and i am tired, but i have this > error: form.clean() > Traceback (most recent call last): > File "", line 1, in ? > File "/home/felipecastel/django1.0_src/django/forms/models.py", line > 208, in clean >self.validate_unique() > File "/home/felipecastel/django1.0_src/django/forms/models.py", line > 236, in validate_unique >if name in self.cleaned_data and f.unique and not is_null_pk: > AttributeError: 'IdeaForm' object has no attribute 'cleaned_data' > and i read the doc over and over again and i cant use the forms. This sounds like more of a usage question then (for instance I see you calling form.clean() manually for some reason), so you should take it to django-users :) -- Collin Grady --~--~-~--~~~---~--~~ 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: I want a pony: Django Cheeseshop
Malcolm Tredinnick wrote: > On Tue, 2008-09-16 at 05:06 -0700, mrts wrote: > > [...] >> setuptools is a necessary evil for the agile developer who frequently >> tracks updates for the bits he relies upon. Hopefully it will be >> improved (the clamor around it is ever-ongoing), but unless we want to >> do it ourselves, we have to accept the state of things. >> > > Wow. You just said we should entirely ditch security because it isn't > convenient. That's exactly the attitude that has made Microsoft the > laughing stock of the professional IT community for the last 15 years. > > Which, sadly, hasn't affected either their profits or their market dominance. > If my original mail had said "nobody should ever use setup tools" or > anything like that, you reply might be valid. Go back and read it. I > said "optional", not "forbidden". There are multiple audiences here. If > Django ever had a hard dependency on setuptools for using third-party > packages it would make it very difficult for system administrators to > use Django because of the large level of security uncertainty and extra > overhead that comes with using it. So, again, it's fine for people who > want to to use setuptools and virtualenv and buildout and eggs and > rinky-dinky-tool-of-choice. People use things knowing that there are > always trade-offs and compromises. It's bad once policy starts being > enforced on something that is simply unusable in certain environments. > Yes, anyone looking for "the one true way" is doomed to disappointment. You only have to review recent correspondence on python-dev to realize that no one person is aware of all the requirements of the various platforms for which modern applications must be packaged. I don't much like the pejorative implication of matching "rinky-dinky-tool-of-choice" with the other listed alternative, however. Personally I think virtualenv is a good solution to a tricky problem. The thing that bugs me most of all is Python developers who assume that the answer to all Python distribution problems is the assumption that a single Python installation can support all required applications. In this day and age it's quite practical to look at distributing the required interpreter as a component of your application or framework. There is no reason why your Python program and mine need have any components in common, and increasingly less reason to enforce this requirement to save disk space. Having said which, Django and other frameworks don't have that luxury: if I'm running Django on 2.4 then every app my Django installation supports also has to run on 2.4. regards Steve --~--~-~--~~~---~--~~ 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: Proposal: refactoring URL resolution
On Mon, 2008-09-15 at 14:10 -0700, Ken Arnold wrote: > I previously brought up a URL resolution refactoring (http:// > groups.google.com/group/django-developers/browse_thread/thread/ > e16bcd24f9e27062/a84b8e58fe2e7786), and was wisely told to hold off on > it. I thought this might be a good time to bring it up again. > > I'm just going to suggest the simplest thing that might possibly work; > please comment. > > URL resolver interface: > - resolve(path) returns (view_function, args, kwargs), just like > existing interface > - reverse(name, *a, **kw) returns URL path > > That's not new. Here's the difference: a URL configuration /is/ a > resolver. We just abstract the special case about importing a module. > For example, an AdminSite is a resolver. It can just inherit from > RegexURLResolver (or whatever). Instead of the ad-hoc resolver in > 'root', it has a 'resolve' method that maybe checks a few special > cases and then calls super.resolve. You don't mention what problem are you trying to solve with this change? Sure, we could do this and certainly make it fully backwards compatible, but why is it needed? You can already put any object you like that has a resolve() method into urlpatterns(). That object can see every single pattern that passes through if it is matched for the pattern ''. We have to *some* kind of root object and it happens to be RegexURLResolver. Right now, in various pieces of client code, I've written classes that variously (a) implements Joe Gregorio's URL patterns, (b) adds support for "name=" prefixes on included URL patterns and (c) looks up the URL correspondence via an external script to determine where to dispatch to. All three of these were written to meet various client needs and work quite happily as part of urlpatterns(). I can't think of a case where I've needed something above that. You clearly have something in mind, so time to spill the beans (please). Regards, Malcolm --~--~-~--~~~---~--~~ 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: I want a pony: Django Cheeseshop
> > apt and rpm don't mix with project-specific packages and versioning > > (virtualenv/buildout). It is just not feasible (or even possible if > > something is built against django-0.96 and something else against > > django-1.0) > > Don't tell that to my laptop and some systems I admin which have > completely parallel installation of Python 2.4 and everything else I > need to do Plone work, all managed by rpms, then. They don't like being > told that what they're doing is apparently impossible. :-) Yes, it's perfectly possible to use Buildout and rpms in conjunction. Zope Corp, who created Buildout, even uses Buildout for development and production deployments using rpms: http://mail.python.org/pipermail/distutils-sig/2007-August/008158.html > setuptools is a necessary evil for the agile developer who frequently > tracks updates for the bits he relies upon. Hopefully it will be > improved (the clamor around it is ever-ongoing), but unless we want to > do it ourselves, we have to accept the state of things. Only a small (and arguably non-evil) slice of the setuptools package is a necessary evil. It would be nice if the namespace support and the "include more metadata about our Python packages" parts of setuptools were separate from the rest of setuptools, so that the distinction between using easy_install and using eggs was a lot clearer. Eggs are just a packaging format, and one that can work complementary to packaging formats such as rpms and dpkgs. Buildout only uses a small slice of functionality from setuptools. It's egg-installation code lives outside setuptools and Buildout entirely in the zc.recipe.egg package (http://pypi.python.org/pypi/ zc.recipe.egg). If someone doesn't like the way zc.recipe.egg handles the install of egg-based packages, it's perfectly possible create a recipe which does things the way you desire. --~--~-~--~~~---~--~~ 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: Proposal: installmedia command - A story for distributing media with apps
On Sep 16, 7:31 pm, Brian Beck <[EMAIL PROTECTED]> wrote: > On Sep 16, 7:22 pm, Julien Phalip <[EMAIL PROTECTED]> wrote: > > > I really like the idea. However, I think there should also be a way to > > configure it to not copy to MEDIA_ROOT but to somewhere else. > > Sure - a --destination flag, defaulting to MEDIA_ROOT, would work. There's also the issue of the application knowing where its media will be installed, so that it can access it from templates. Let's say I just did manage.py installmedia myapp and all of myapp's media got copied into MEDIA_ROOT/myapp/{css,js}/. Should I assume in my templates that the files are available at {{ MEDIA_URL }}/myapp/ {css,js}/? Or maybe there should be a settings variable, something like APP_MEDIA_URLS = { 'myapp': 'some/other/path', ... } so that the app can use {{ APP_MEDIA_URLS.myapp }}/myapp/{css,js}/. This doesn't seem like a great solution though, because there's no real "standard" for which {% blocks %} to override in an app to add css/js; maybe this configuration step should just be left to the person using the app. --~--~-~--~~~---~--~~ 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: Proposal: installmedia command - A story for distributing media with apps
On Wed, Sep 17, 2008 at 7:47 AM, sciyoshi <[EMAIL PROTECTED]> wrote: > > On Sep 16, 7:31 pm, Brian Beck <[EMAIL PROTECTED]> wrote: >> On Sep 16, 7:22 pm, Julien Phalip <[EMAIL PROTECTED]> wrote: >> >> > I really like the idea. However, I think there should also be a way to >> > configure it to not copy to MEDIA_ROOT but to somewhere else. >> >> Sure - a --destination flag, defaulting to MEDIA_ROOT, would work. > > There's also the issue of the application knowing where its media will > be installed, > so that it can access it from templates. Let's say I just did This is not really a problem, since the media will always be under //.. A problem would be referencing images, and media in css/js files. Currently, in all our projects we use /site_media/ as the MEDIA_URL, so this not a problem. But for a true solution, there should be a preprocessor for css/js to use the MEDIA_URL within it. Another problem which we havent solved, is overrides. E.g., when we use a "plugabble"/reusable app with its own media, and we want to override this in our project, how should the collect media command work ? Anyway, I've attached our media app (with the command, etc). If you want any changes to be included, please do tell me. Regards Rajeev J Sebastian --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- dynamo_media.tar.bz2 Description: BZip2 compressed data
Re: Proposal: installmedia command - A story for distributing media with apps
On Sep 16, 10:49 pm, "Rajeev J Sebastian" <[EMAIL PROTECTED]> wrote: > A problem would be referencing images, and media in css/js files. > Currently, in all our projects we use /site_media/ as the MEDIA_URL, > so this not a problem. But for a true solution, there should be a > preprocessor for css/js to use the MEDIA_URL within it. CSS can refer to images by their path relative to the CSS file, so if your media tree looks like: media/css/base.css media/images/icon.png Then base.css can do: background-image('../images/icon.png') ...so no preprocessing needed there. But referring to *another app's* images is another story. And JavaScript... well, don't reference images in JavaScript. > Another problem which we havent solved, is overrides. E.g., when we > use a "plugabble"/reusable app with its own media, and we want to > override this in our project, how should the collect media command > work ? I imagined this working just like templates. By *convention* apps can lay out their media directories like media/appname. So there's nothing stopping your app from including, say, media/anotherapp/css/ base.css, and we can say that whichever app is in INSTALLED_APPS first wins, just like with templates. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
django.VERSION changes
A while back I proposed changing the way the ``django.VERSION`` tuple is set up. That discussion petered out a bit, until I brought it up with Jacob just before the 1.0 release. At the time, we felt it wasn't possible to do it before we rolled 1.0 (this was, due to my absent-mindedness, about ten minutes before we tagged the release, so it's my fault this didn't happen prior to 1.0), but now I'd like to revisit this and get it done so we have something a bit more sensible going forward. I'm writing this mostly as an explanation of what I plan to do; if there aren't any well-founded objections, I'll make the necessary changes and commit them before we create the 1.0.x branch. The problems with the current scheme Right now, ``django.VERSION`` is a 3-tuple whose format has been known to vary wildly according to what we're doing at a given moment. This has led to two major problems: 1. Because the third item in the ``VERSION`` tuple has been used for qualifiers like 'pre', 'beta', etc., we only have two items available for the actual version number. This has been known to cause hilarious results in the case of releases like, say, 0.96.3, which has to be (0, 96.3, None) (stop and think about how IEEE floats get printed, and you'll see the issue here). 2. That third item has never followed any really predictable format, except for the period of the 1.0 alpha/beta releases. This makes it difficult to tell what sort of Django codebase you're looking at without thinking about it and possibly doing some archaeology. I don't see any good way to deal with these issues while retaining the current 3-tuple, so... The format of ``django.VERSION`` going forward == Based on a good suggestion from Steve Holden, I'm going to change ``django.VERSION`` to follow, as closely as possible, the format of Python's own ``sys.version_info``. This means it will become a 5-tuple, whose elements are, in order: major version, minor version, micro version, release level, serial. The Python docs don't actually define these terms clearly, but for Django's use I'm going to lay out what these mean and what values they can take, inferring at times from how Python's done it (I've been reading the history of Include/patchlevel.h to get a feel for the way that's evolved over time... fun fun). So here goes: "major" The major version number of the Django release, e.g., 1 for the 1.x releases. "minor" The minor version number of the Django release, e.g., 0 for the 1.0.x releases, 1 for the 1.1.x release, etc. "micro" The micro version number of the Django release, e.g., 1 for a release number 1.0.1, 2 for a release number 1.0.2, etc. "release level" A short string describing the type of release. Value will be one of: "alpha", "beta", "rc" (for release candidates, "final". "serial" For situations where we do more than one release of a given level, the incremental number of the release (e.g., 1 for "alpha 1", 3 for "beta 3", etc.). How this will work == For the most part, this all works pretty simply and intuitively. Let's consider the case of the eventual 1.1 release and, for sake of example, assume we do two alpha releases, two beta releases, one release candidate and then the final 1.0. During that process, the ``VERSION`` tuple would evolve as follows: * For Django 1.1 alpha 1: (1, 1, 0, 'alpha', 1). * For Django 1.1 alpha 2: (1, 1, 0, 'alpha', 2). * For Django 1.1 beta 1: (1, 1, 0, 'beta', 1). * For Django 1.1 beta 2: (1, 1, 0, 'beta', 2). * For Django 1.1 release candidate 1: (1, 1, 0, 'rc', 1). * For the final 1.1 release: (1, 1, 0, 'final', 0). The only tricky bit is what to do immediately after a release; for example, after we release 1.1, what happens to ``django.VERSION`` in trunk as we gear up development for 1.2? Taking a cue once again from Python, the answer is that we go from this, which is 1.1 final:: (1, 1, 0, 'final', 0) to this, which denotes dev work in trunk for 1.2 prior to any alpha release:: (1, 2, 0, 'alpha', 0) In other words, a release level of "alpha" and a serial of 0 indicates we're working toward the release specified by the rest of the tuple, but have not yet reached the point of issuing alpha versions of it. The ``django.get_version()`` function will be rewritten to piece this together as follows: * For a "real" release like, say, 1.1, the tuple (1, 1, 0, 'final', 0) will become the printed string "1.1 final". * For an alpha, beta or RC, a tuple like (1, 1, 0, 'beta', 2) will become the printed string "1.1 beta 2". (1, 1, 0, 'rc', 1) will become "1.1 rc 1". * For the one special case of checkouts from trunk prior to the beginning of alpha releases, a tuple like (1, 2, 0, 'alpha', 0) will become the printed string "1.2 pre-alpha". In all cases, if we're on an SVN checkout we append the revision number, e.
Re: Proposal: installmedia command - A story for distributing media with apps
On Sep 16, 11:05 pm, Brian Beck <[EMAIL PROTECTED]> wrote: > On Sep 16, 10:49 pm, "Rajeev J Sebastian" <[EMAIL PROTECTED]> > wrote: > > > A problem would be referencing images, and media in css/js files. > > Currently, in all our projects we use /site_media/ as the MEDIA_URL, > > so this not a problem. But for a true solution, there should be a > > preprocessor for css/js to use the MEDIA_URL within it. > > CSS can refer to images by their path relative to the CSS file, so if > your media tree looks like: > > media/css/base.css > media/images/icon.png > > Then base.css can do: background-image('../images/icon.png') > > ...so no preprocessing needed there. But referring to *another app's* > images is another story. And JavaScript... well, don't reference > images in JavaScript. We use the convention that there should be a Javascript variable called MEDIA_URL defined somewhere in a base template that lets Javascript access it; seems like this might be a useful convention to adopt. > > Another problem which we havent solved, is overrides. E.g., when we > > use a "plugabble"/reusable app with its own media, and we want to > > override this in our project, how should the collect media command > > work ? > > I imagined this working just like templates. By *convention* apps can > lay out their media directories like media/appname. So there's > nothing stopping your app from including, say, media/anotherapp/css/ > base.css, and we can say that whichever app is in INSTALLED_APPS first > wins, just like with templates. For CSS, there's a couple ways that this might possible. Let's say myapp wants to distribute some default CSS; then it could actually provide two separate files: myapp/media/myapp/css/style_base.css: #myapp div.something { /* custom styles for the app */ } myapp/media/myapp/css/style.css: @import url(./style_base.css); This way, the project using the app can customize the CSS or replace/ exclude it completely (by excluding the import line), without having to change anything inside myapp proper. django-compress might be useful in this situation; it could automatically parse the @imports in CSS and generate a compressed version including the right files. I'm not sure though that all of this is worth it; it seems like we're trying to optimize for the case where somebody a user simply drops an app into their project, runs installmedia, and never customizes anything beyond that. In reality, the templates and CSS are most likely going to be customized (although JS is another story), so maybe this sort of "inheritance" isn't really needed. Which reminds me - I think it would be really nice if there was some sort of script/style manager in Django (similar to the django.forms media): {% extends 'base.html' %} {% css 'myapp/css/stuff.css' 'myapp/css/morestuff.css' %} {% js 'myapp/js/stuff.js' %} {% block content %} ... {% endblock %} and then in the base template {% css %} {% js %} {% block content %}{% endblock %} Django could then even check in a list of directories to find the appropriate files (similar to the way template lookups work now) and include the first one found. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---