[Feature] On CommandError, sys.exit(1)

[Ben Liyanage]

Hey,

What do you guys think about this feature request?

> On CommandError, sys.exit(1)

It would be pretty easy to do the sys.exit(1) right here:

https://github.com/django/django/blob/df0a446fd4c864c003e4f941b5b7abd6f10c9427/django/core/management/__init__.py#L289

This would allow you to fail an automated build when migrations (or any
other management command) failed.  Currently I see no way of doing that.

Beyond that, I noticed that the sys.exit(1) is not very consistently
applied on the makemigrations management command (for example, it is not
called when the --merge parameter is supplied).

I can do the PR for the CommandError thing (unless anyone sees a reason not
to, or that would not work/there is a better place to put it).

-- 
*Ben Liyanage *|* Software Engineer *|* Rentlytics, Inc.*
Phone: (410) 336-2464 | Email: bliyan...@rentlytics.com
1132 Howard Street, San Francisco CA 94107
Visit our Website  | Watch our Video


-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADgLBUOGCwMqV052WgA-o3PPrT5tb2%3DT%3D9vc%2BO5JZRQYZJCC%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: should manage.py test run system checks?

[Žan Anderle]

Adam: I don't think they should be optional, or if they are, they should be 
opt-out. The checks are a brilliant guard against error, but not running 
them as part of test invites them not being run at all in a TDD workflow, 
as often code can be developed with nothing but running the tests. It is 
also surprising that *only* test doesn't run them, since every other manage 
command 
does.


I agree with this. I don't see why an opt-out option is not valid? 

Dne torek, 20. oktober 2015 02.48.29 UTC+2 je oseba Tim Graham napisala:
>
> A ticket [1] and pull request [2] note that `manage.py test` ran the 
> system checks in Django 1.7 (as a side effect of call_command('migrate')), 
> but this is no longer the case in Django 1.8 since call_command() doesn't 
> trigger the system checks anymore.
>
> me: I'm of the opinion that running the system checks as part of the 
> manage.py 
> test command should be opt-in (for example, by writing a test that 
> asserts the call_command('check') output is empty. For example, when 
> debugging a single test, it doesn't seem necessary to have the overhead of 
> running check. As more options are added to check (e.g. #25500 
> ), a default implementation 
> as currently proposed could become increasing inflexible. I'd like to 
> document the change in the 1.8 release notes and suggest the alternative.
>
>
> Adam: I don't think they should be optional, or if they are, they should 
> be opt-out. The checks are a brilliant guard against error, but not running 
> them as part of test invites them not being run at all in a TDD workflow, 
> as often code can be developed with nothing but running the tests. It is 
> also surprising that *only* test doesn't run them, since every other 
> manage command does.
> At YPlan we couldn't do without them as part of tests. Our aforementioned 
> 'installed packages' check saves a lot of time that would otherwise be 
> wasted understanding confusing error messages about imports not working, 
> and our other custom checks do verification similar to Django's, for issues 
> that without resolution it does not make sense to even attempt do any 
> tests. Also we don't notice any real overhead, we can still get a single 
> test to run in 1 second (with --keepdb :) ) despite all our extra messing 
> around with pip freeze etc.
>
> Other opinions?
>
> [1] https://code.djangoproject.com/ticket/25415
> [2] https://github.com/django/django/pull/5293
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2ef0f6de-4f1c-4067-8154-b56ff11025d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

[Reid Ransom]

Yesterday, I noticed a couple users had created multiple accounts with
different capitalization.  One person had 4 accounts.  I've also gotten
a lot of complaints from users that were having trouble logging in.  My
response was generally "Use the forgot password link." but now I'm 
realizing that they probably had difficulty remembering their username
capitalization they used during registration or didn't know the
capitalization our staff used to create their account.

I was already working with a custom user model and all my
conflicting usernames were for the same people so this wasn't too hard
to fix.  Still I would expect Django to want devs to start with case-
insensitive for the reasons already cited in this thread but also since
it's much easier to switch to case-sensitive later if that's what you
really want.

Shai- Could an upgrade path for what you proposed be to change the
AUTH_USER_MODEL setting?


On Wednesday, October 21, 2015 at 5:39:47 PM UTC-4, Shai Berger wrote:
>
> Hi, 
>
> On Thursday 22 October 2015 00:01:24 Paul Egges wrote: 
> > Perhaps I'm missing something, but this would not change current users, 
> > only the creation of new users. It seems that logins would still be case 
> > sensitive. 
>
> Not the way Reid presented it: 
>
> > > Le mercredi 21 octobre 2015 15:44:55 UTC-4, Reid Ransom a écrit : 
> > >> Is it reasonable to consider changing the default for usernames to be 
> > >> case-insensitive in 2.0? 
>
> I think, though, it would be easy enough for us to provide a new, case- 
> insensitive base class for users, and change the recommendations in our 
> documentation to tell users to inherit that rather than the current 
> AbstractBaseUser and AbstractUser. We could also write a simple management 
> command to validate lower-case uniquness and turn all usernames to 
> lowercase, 
> as preparation for changing the login and registration logic. 
>
> These could all be done outside of core, and perhaps they should be -- the 
> only point I see for including them in core is the risk that, as a 
> developer, 
> if core doesn't make you think about it from the get-go, by the time you 
> decide to make the change you may be stuck with conflicting (lower-case 
> equal) 
> usernames in your database. But frankly, I would guess that this problem 
> does 
> not really occur very often; that for most sites, if they decide to switch 
> to 
> case-insensitive usernames, there would be no problem. 
>
> Regretfully, we can't just switch Django to do that, because of the few 
> sites 
> who will have a problem, and no clear upgrade path. 
>
> Shai. 
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4d33cc01-84bd-49b8-8d90-3770a2766921%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

[Paul Egges]

Yeah, I was referring to the post by Daniel at the start of the thread, not
Reid's comment.

I would be -1 on changing the check of usernames at login to
case-insensitive. But I would be +1 with preventing the creation of new
usernames which would match existing usernames in a case-insensitive manner.

On Wed, Oct 21, 2015 at 3:39 PM, Shai Berger  wrote:

> Hi,
>
> On Thursday 22 October 2015 00:01:24 Paul Egges wrote:
> > Perhaps I'm missing something, but this would not change current users,
> > only the creation of new users. It seems that logins would still be case
> > sensitive.
>
> Not the way Reid presented it:
>
> > > Le mercredi 21 octobre 2015 15:44:55 UTC-4, Reid Ransom a écrit :
> > >> Is it reasonable to consider changing the default for usernames to be
> > >> case-insensitive in 2.0?
>
> I think, though, it would be easy enough for us to provide a new, case-
> insensitive base class for users, and change the recommendations in our
> documentation to tell users to inherit that rather than the current
> AbstractBaseUser and AbstractUser. We could also write a simple management
> command to validate lower-case uniquness and turn all usernames to
> lowercase,
> as preparation for changing the login and registration logic.
>
> These could all be done outside of core, and perhaps they should be -- the
> only point I see for including them in core is the risk that, as a
> developer,
> if core doesn't make you think about it from the get-go, by the time you
> decide to make the change you may be stuck with conflicting (lower-case
> equal)
> usernames in your database. But frankly, I would guess that this problem
> does
> not really occur very often; that for most sites, if they decide to switch
> to
> case-insensitive usernames, there would be no problem.
>
> Regretfully, we can't just switch Django to do that, because of the few
> sites
> who will have a problem, and no clear upgrade path.
>
> Shai.
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAD4jHOKk3p6kh7sRrUp4G6JxCA-CpeV7bhuABE0PwSUBW8EO-w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.