liuyang1520 / django-command-extensions

Automatically exported from code.google.com/p/django-command-extensions
MIT License
0 stars 0 forks source link

Break up django_extensions into namespaces #51

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
As a contributor to django-extensions and a user of it on almost every
project, I'm concerned about what seems like a lack of focus for the
project, and the potential for ever-increasing bloat.

Originally this project was for convenient extra management commands.  This
isn't very focused, but it's reasonable, as "managing a project" is at
least a well-defined task area.  

Now, with the additions of fields, I no longer have any sense what the
purpose of this project is.  Is it a general catch-all for any piece of
code anyone wants to use that isn't in Django trunk?  Is it just
djangosnippets.org in installable form?  Aren't we breaking the
reusable-apps rule "do one thing and do it well" in a big way?

Basically, I think that django-extensions should remain for management
commands only (even though sadly the name no longer reflects that), and a
new project (maybe django-magicfields or something?) could be started for
collecting miscellaneous useful model fields and base classes.

Original issue reported on code.google.com by carl.j.meyer on 15 Sep 2008 at 2:29

GoogleCodeExporter commented 8 years ago

Original comment by carl.j.meyer on 15 Sep 2008 at 2:37

GoogleCodeExporter commented 8 years ago
+1 keeping i just management commands.

There are a ton of little things (man of which are hanging out on pinax/core) 
which I
would love to see in a reusable django app, but this is not that app.

fields should be moved out.
jtabuer was talking about having a django-stuff or django-core-extensions 
project
which is better suited for those things.

Original comment by doug.nap...@gmail.com on 16 Sep 2008 at 4:36

GoogleCodeExporter commented 8 years ago
Well we already had this discussion so I really don't know why more people 
didn't
weigh in then.  The outcome of that discussion was that it was decided that we 
would
change the name to Django Extensions because there was a desire to encapsulate 
other
useful utilities into the project.  

I think the only thing needed at this point is some sort of namespacing so you 
can
say in your INCLUDED_APPS something like:

'django_extensions.fields',
'django_extnesions.commands',

etc...

That would probably solve the problem correct?

Original comment by mtr...@gmail.com on 16 Sep 2008 at 6:27

GoogleCodeExporter commented 8 years ago
One nice thing about the namespaces is that 'django_extensions.*' works as well.

Another thing we might want to think about when discussing this is; should all 
the
extension commands be in one namespace. We already install 24 extra commands 
which
could be argued also 'bloats' ./manage.py

I hope we can get some good discussion about this on the mailinglist.

Original comment by v.oostv...@gmail.com on 17 Sep 2008 at 3:23

GoogleCodeExporter commented 8 years ago
continued the conversation on the mailing list:

http://groups.google.com/group/django-extensions/browse_thread/thread/4a2d12b8c6
1d648c

Original comment by carl.j.meyer on 17 Sep 2008 at 3:48

GoogleCodeExporter commented 8 years ago

Original comment by carl.j.meyer on 22 Sep 2008 at 2:29

GoogleCodeExporter commented 8 years ago
Starting to close down bugreports on google code.
Hopefully we can continue further and more fruitful discussion about this on the
mailinglist!

Original comment by v.oostv...@gmail.com on 11 May 2009 at 8:37