Django startproject template enhancement proposal
Hi all,
There's a pattern I like to use in my projects which I'd like to
suggest for django startproject.
It looks like:
project_name/
setup.py
src/
myapp1/
myapp2/
project_name/
settings.py
urls.py
manage.py
wsgi.py
My settings.py here uses environment variables for everything to
override defaults.
Setup.py here allows:
- Adding an entry point,
- Installing all apps as packages,
- Installing test dependencies with extra_requires and pip install
project_name[test],
- Adding runtime dependencies.
For example, with that:
entry_points = {
'console_scripts': [
'project_name = project_name.manage:main',
],
},
And such a manage.py:
def main():
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "project_name.settings")
from django.core.management import execute_from_command_line
execute_from_command_line(sys.argv)
if __name__ == "__main__":
main()
Installing the package will add the project_name command, allowing to
run `project_name migrate` for example from any directory.
I know it's too opinionated to add that to django, but I'd like to
open a discussion here and perhaps there's something we might find
worth changing in django's default project template.
Thanks for reading !
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CALC3Kacfi68SAA%3DC0AVX%2B3r8dPwOM3cJcBrdiC4CpZEF-NiCCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: Proposal on Custom Indexes - Google Summer of Code
What about calling the attribute something like "constraints" similar to how it's done in SQLAlchemy [1]? For now the attribute can just contain a list of Index() instances but that would also lay grounds for supporting check constraints and other related table level options. Moritz [1] http://docs.sqlalchemy.org/en/latest/core/constraints.html Am 10. März 2016 09:57:47 MEZ, schrieb "Anssi Kääriäinen" : >On Wed, Mar 9, 2016 at 11:16 PM, akki wrote: >>> >>> Of course, this is a great thing to have. But I wonder if we can do >>> something to prevent pushing non-indexes to the indexes attribute of >>> Meta. Having Meta.indexes = [CheckTypeConstraint(foo__in=['foo', >>> 'bar'])] doesn't read correctly. >> >> >> Perhaps it would be best not to mix constraints and indexes. I would >like to >> know your thoughts on stopping to create indexes explicitly for >unique >> constraints because all database do that automatically because that >only >> gives a performance degradation as far as I know. > >The point is that if the Index class generates the full SQL for the >index creation, then the Index classes can be used to run arbitrary >changes to the database. Having the ability to run arbitrary SQL is >great, but this will lead to users having all sorts of non-indexes in >the indexes meta attribute. I'd like to avoid that if possible. > > - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/34AC0787-76E3-47CB-B3D2-3D87703B7CED%40googlemail.com. For more options, visit https://groups.google.com/d/optout.
Re: Django startproject template enhancement proposal
On Saturday, March 12, 2016 at 5:29:55 PM UTC+1, is_null wrote: > > I know it's too opinionated to add that to django, but I'd like to > open a discussion here and perhaps there's something we might find > worth changing in django's default project template. > Imo it should stay as minimal as it is currently. Since we do allow you to specify --template to startproject, you can prepare a default project layout that suits you. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/95a6a70e-0499-456d-8dfe-326032710a64%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Fellow Report - March 12, 2016
Triaged --- https://code.djangoproject.com/ticket/26326 - Admin related object pop-ups not working (worksforme) https://code.djangoproject.com/ticket/26327 - Add JSON_AGG to contrib.postgres (accepted) https://code.djangoproject.com/ticket/26313 - Show labels next to ManyToMany with raw_id_fields (wontfix) https://code.djangoproject.com/ticket/26329 - StaticFilesStorage permits leading slash, CachedStaticFilesStorage doesn't (accepted) https://code.djangoproject.com/ticket/26332 - BaseCache.get_or_set() doesn't always return a value (accepted) https://code.djangoproject.com/ticket/26334 - django.contrib.auth forms shouldn't strip whitespace from password fields (accepted) https://code.djangoproject.com/ticket/26335 - Show SQL if migration fails (needsinfo) https://code.djangoproject.com/ticket/26344 - EmailMultiAlternatives ignores alternatives when it has attachments and body is empty (accepted) https://code.djangoproject.com/ticket/26346 - Error in makemigrations while changing DateTimeField default value from timezone aware datetime to naive datetime.now() (duplicate) https://code.djangoproject.com/ticket/26349 - A cookie named "?" breaks CSRF (invalid) Authored https://github.com/django/django/pull/6263 - Fixed #26324 -- Fixed DurationField with fractional seconds on SQLite. https://github.com/django/django/pull/6284 - Fixed #26294 -- Clarified call_command()'s handling of args and options. Reviewed/committed -- https://github.com/django/django/pull/6251 - Fixed #26325 -- Fixed crash in MultiPartParser on filenames that normalize to an empty string. https://github.com/django/django/pull/6222 - Fixed #25933 -- Allowed an unprefixed default language in i18n_patterns(). https://github.com/django/django/pull/6214 - Fixed #26289 -- Enabled shell tab completion on systems using libedit. https://github.com/django/django/pull/6008 - Fixed #25971 -- Made BrokenLinkEmailsMiddleware ignore APPEND_SLASH redirects. https://github.com/django/django/pull/5876 - Fixed #26033 -- Added Argon2 password hasher. https://github.com/django/django/pull/6250 - Fixed #26332 -- Fixed a race condition in BaseCache.get_or_set(). https://github.com/django/django/pull/6269 - Fixed #25865 -- Made OSMGeoAdmin require GDAL only if transformation is needed. https://github.com/django/django/pull/6131 - Fixed #25143 -- Added ArrayField.from_db_value(). https://github.com/django/django/pull/6281 - Fixed #26239 -- Added a note about how auto_now works with QuerySet.update() https://github.com/django/django/pull/6280 - Fixed #26343 -- Sent user_login_failed signal if an auth backend raises PermissionDenied. https://github.com/django/django/pull/6099 - Fixed #25364 -- Added support for all selenium's browsers in tests. https://github.com/django/django/pull/6283 - Fixed #26283 -- Fixed removal of trailing nulls for SplitArrayField. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/c8dd6258-22e4-4100-8fdd-9555084624b5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Revisiting multiline tags
On 12 March 2016 at 05:31, Curtis Maloney wrote: I think this conversation needs to come to a conclusion, and that >> conclusion should be simple. Several people have asked a very simple >> question of the purists: what is the "correct" way of writing tags which >> by nature need to be very long, without line breaks and without them >> being 400 characters long. If no acceptable answer can be given, we need >> to just implement the line break mechanic and give the developers back >> their whitespace. >> > > As pointed out by Josh in another email, I wrote a patch to permit > multi-line tags. I asked for feedback. I got _none_. > > If people really wanted this feature, why didn't we hear more about it? > What can we do to get more people to know about it, and to give more > feedback? > > I would recommend you review the history of this discussion, collect the > pros and cons, formulate a DEP, and we can go from there. > > I'm quite sure the patch will still work fine. > > Presumably you're talking about this: https://github.com/django/deps/pull/3/files I'm not sure what feedback you're expecting, but if +1's are what's needed, then here you go: +1. The thing is, this feature is a nice to have but no show stopper. The first time a developer runs into this (by trying the obvious and finding it doesn't work), they'll check the documentation, shrug their shoulders at the weird Django developers and get on with their job. Perhaps 1% will go to the effort of seeing if it has been proposed, find it's been mentioned several times and think "someone is working on it" and get on with their job. Perhaps 1% of those will note it hasn't been done yet, dig deeper and find your proposal and the various bugs, note it's been blocked, figure it's a lost cause and get on with their job. If this change requires a horde of developers waking up and calling for it, then it's never going to happen. The current situation will however continue to cause wasted developer time until eternity. Simply because there is no obvious reason why it shouldn't work. It's not ambiguous, it's not going to confuse anyone, it's just one of those little things that makes computers just a little bit more user friendly. Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CADWG95v7eMb8u85PyS3MsigXMVoKs3a_H9zx8aGJBsetBaWyLQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
