Proposal: make 1.4 more explicit
Patryk Zawadzki
Currently Django has its own concept of namespacing (apps) and mostly
ignores Python modules. I'd like to propose using Python paths
wherever we can instead of apps. This would solve a lot of problems
with conflicting submodule names that plague maintainers of reusable
apps and frameworks. Currently if you try to provide a base
frobnicator model and you choose to do so in
"fooframework.frobnicator.models", you pretty much forbid the users
from putting derived classes in a local module named
"frobnicator.models". Bad things happen when two apps start to provide
"frobnication_tags".
I propose the following:
* make the internal model handling operate on full paths to the
classes, rather than just the app names and class names
* make the DB table names use full python paths instead of just the
app name and the class name
* make templatetag loading use full paths rather than just the suffix
* allow fully qualified templatetag names ("{%
foo.templatetags.frobnication_tags.frobnicate baz %}") and possibly
loading aliases ("{% import foo.bar.tags as bar %}") to cover the case
when conflicts are hard to avoid (different app authors etc.)
* for 1.4 provide a number of fallback settings that can be used to
enable legacy behavior in each of the first three points
PS: http://code.djangoproject.com/ticket/12772
PPS: Please don't shoot me. :>
--
Patryk Zawadzki
I solve problems.
Luke Plant
> I propose the following:
> * make the internal model handling operate on full paths to the
> classes, rather than just the app names and class names
> * make the DB table names use full python paths instead of just the
> app name and the class name
> * make templatetag loading use full paths rather than just the suffix
> * allow fully qualified templatetag names ("{%
> foo.templatetags.frobnication_tags.frobnicate baz %}") and possibly
> loading aliases ("{% import foo.bar.tags as bar %}") to cover the case
> when conflicts are hard to avoid (different app authors etc.)
I general I think this is a noble goal (although some points are
debatable)...
> * for 1.4 provide a number of fallback settings that can be used to
> enable legacy behavior in each of the first three points
but this is where it falls down, because the devil is in the details
with regards to backwards compatibility.
Settings to control this is not really an option, because it means you
have to get everything upgraded together, which is just infeasible with
the current app ecosystem. For each bullet point, you'll need a more
fine-grained approach that allows upgrading at least on the level of an
individual app, and users of that app to be able to use old apps.
We would also need tools to migrate existing tables. Don't forget the
contenttypes app, which contains data that use the existing app names.
Remember also that we don't have any tools in core for upgrading
existing tables or data.
This sounds to me more like the kind of change we might do for Django
2.0, not 1.4...
> PPS: Please don't shoot me. :>
No-one feels like shooting you - because we presume that if this is a
serious proposal, you're not expecting other people to do all the work,
and if it's not a serious proposal, we'll just ignore it :-)
Regards,
Luke
--
"If you're not part of the solution, you're part of the
precipitate." (Steven Wright)
Luke Plant || http://lukeplant.me.uk/
Patryk Zawadzki
> On 31/03/11 19:35, Patryk Zawadzki wrote:
>> * for 1.4 provide a number of fallback settings that can be used to
>> enable legacy behavior in each of the first three points
> but this is where it falls down, because the devil is in the details
> with regards to backwards compatibility.
>
> Settings to control this is not really an option, because it means you
> have to get everything upgraded together, which is just infeasible with
> the current app ecosystem. For each bullet point, you'll need a more
> fine-grained approach that allows upgrading at least on the level of an
> individual app, and users of that app to be able to use old apps.
I meant a set of separate settings. Like a list of apps that should
still use legacy table names. As for template loading, the ticket I
mentioned in the original post has a backwards-compatible patch. A
future version of Django can just remove the fallback part of the
code. The hardest part is making the internals work with fully
qualified paths.
> We would also need tools to migrate existing tables. Don't forget the
> contenttypes app, which contains data that use the existing app names.
> Remember also that we don't have any tools in core for upgrading
> existing tables or data.
It would be much easier if Django contained a migration mechanism that
apps such as the content types framework could use. We also have to
support a way to convert existing fixtures.
> This sounds to me more like the kind of change we might do for Django
> 2.0, not 1.4...
I hope that it would be possible to roll these out gradually. newforms
didn't happen overnight either :)
Alex Kamedov
Hi group,
Currently Django has its own concept of namespacing (apps) and mostly
ignores Python modules. I'd like to propose using Python paths
wherever we can instead of apps. This would solve a lot of problems
with conflicting submodule names that plague maintainers of reusable
apps and frameworks. Currently if you try to provide a base
frobnicator model and you choose to do so in
"fooframework.frobnicator.models", you pretty much forbid the users
from putting derived classes in a local module named
"frobnicator.models". Bad things happen when two apps start to provide
"frobnication_tags".
I propose the following:
* make the internal model handling operate on full paths to the
classes, rather than just the app names and class names
* make the DB table names use full python paths instead of just the
app name and the class name