I am not a Django contributor, just a user. Whether it's github or
bitbucket or something else, the more important question is stick with the
current system and workflow as well as policies or move the code and then
of course also have a somewhat different workflow when you start using
Wasn't the reason why Django 1.4 should still support Python 2.5 because of
RHEL 5? If so, RHEL 5 never had official Python 2.5 support but only
supported Python 2.4. RHEL 6 does not support 2.5 either, its Python
version is 2.6. What is the reason that Django 1.4 needs to support Python
2.5?
I agree with others that this is better left to tools such as fabric/cuisine
as they are build to handle these kind of tasks:
http://readthedocs.org/docs/fabric/en/latest/api/contrib/project.html
--
You received this message because you are subscribed to the Google Groups
"Django developers"
Carl, why not have django-admin.py startproject create a site_root directory
and
within it a project_root directory by default if issued from within e.g.
example.com (the outermost container/directory e.g. a virtualenv):
example.com <-- mkvirtualenv example.com; non-Python stuff somehow
> I think we should add a dedicated "Python path and project layout" page,
> and link to it from the tutorial and elsewhere. This gets way too
> complex to load onto beginners right away in the tutorial.
>
IIRC then this page has been proposed before and ultimately not been done
because the
you don't need to start from scratch as there's
https://github.com/codekoala/django-axes
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
>
> +0 on webdesign, since it's functionality that's probably in transient
> use by the more invisible members of our community. If it were more
> fleshed out, I'd say leave it, but since it's just that single
> function, it should probably go eventually.
>
I'd miss it even though it's just a
I'd like to see Django become a bit more like Colony [0], maybe spiced
up with a shoot of ZeroMQish behavior and Mongrel2 on top :-)
In my opinion that would be very interesting for you, you could
justify it as being worthy a PhD thesis and a lot of projects in the
FLOSS community could
> You do make a good point. It's not just that NoSQL systems lack
> features (transactions, schema, relations) that are common to SQL-
> based systems
Actually most graph databases (such as neo4j) which are all considered
NoSQL, have all those features you just mentioned (ACID, relations,
Speaking of bottlenecks ... imho Waldemar and Thomas should be core
devs in addition to
the proposed process of getting more/better community review on Django-
nonrel before a merge into trunk can happen.
--
You received this message because you are subscribed to the Google Groups
"Django
Speaking of bottlenecks ... imho Waldemar and Thomas should be core
devs in addition to
the proposed process of getting more/better community review on Django-
nonrel before a merge into trunk can happen.
--
You received this message because you are subscribed to the Google Groups
"Django
That's certainly a move in the right direction so +1 from me too. The
problem of
backporting correlates with how much time passes between any release
i.e. long time between releases gives bigger pita with backporting.
Even more so because you have several version control systems etc.
etc. (not
That's certainly a move in the right direction so +1 from me too. The
problem of
backporting correlates with how much time passes between any release
i.e. long time between releases gives bigger pita with backporting.
Even more so because you have several version control systems etc.
etc. (not
That's certainly a move in the right direction so +1 from me too. The
problem of
backporting correlates with how much time passes between any release
i.e. long time between releases gives bigger pita with backporting.
Even more so because you have several version control systems etc.
etc. (not
> My company had same problem with project layout. We solved it by
> creating django-starter project. django-starter is already used by 10
> or more projects and it seems, that this solution works.
>
> https://bitbucket.org/sirex/django-starter/src
That does not seem to work with pip and virtual
> My company had same problem with project layout. We solved it by
> creating django-starter project. django-starter is already used by 10
> or more projects and it seems, that this solution works.
>
> https://bitbucket.org/sirex/django-starter/src
That does not seem to work with pip and virtual
> I think, it's a good idea to add new option to startapp command
There is django-extensions which has a create_app command that takes a
--template switch.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email
It is actually so that with using __future__ and >=2.6 you already have
most of the things available from Python 3 e.g. print() rather than
print. See table at the bottom of
http://docs.python.org/dev/library/__future__.html#module-__future__
Sure, everybody is raving about Python 3 but 2.6
18 matches
Mail list logo
