Re: Stalebot on djangoproject.com issues

[Sarah Boyce]

>From what it sounds, I guess the main value was prompting a one time spring 
clean. As there are not that many issues open in djangoproject.com and all 
issues will have been re-validated, I think it makes sense to remove it to 
reduce this additional burden/frustration.

There are configurations around stale PR closing which I think makes more 
sense in general (maybe not for djangoproject.com as there are not many 
PRs), as other people might be reluctant to work on something if there is 
an open PR and it prompts someone to decide if they want to come back to 
this if they have just forgotten for example.

On Wednesday, 5 April 2023 at 23:30:54 UTC+2 Tim Graham wrote:

> Hello,
>
> In October 2022, a stalebot was activated for djangoproject.com issues:
>
> https://github.com/django/djangoproject.com/issues/1219
> https://github.com/django/djangoproject.com/pull/1220
>
> It comments on an issue if there's no activity in the last six months: "This 
> issue has been automatically marked as stale because it has not had recent 
> activity. It will be closed if no further activity occurs. Thank you for 
> your contributions."
>
> The bot closes the issue if there's no activity in the next seven days.
>
> I didn't see much discussion among the djangproject.com team outside of 
> the issue and PR,  but the rationale from the issue is this: "Idea copied 
> from DRF PR #8423 
>  - Add a 
> StaleBot, configured with the lowest possible run limit. The intent here 
> is to help us sweep through the issue and pull request backlog, and review 
> what does and does not need to remain open at this point in time."
>
> Here is what I said at the time: "I think this is a lame way to handle 
> old issues. The result seems to be Carlton triaging all issues that the bot 
> comments on. You could have asked him to do that without a bot adding 
> noise. Should a useless "issue still valid" comment be required every 180 
> days? Why not have a human triage each issue now that more people are 
> maintaining this site? Using a bot comes off to me as passive aggressive. 
> Why try to automatically discard years of issues (even if minor)? It's not 
> like the passage of time or lack of activity means the problem went away. A 
> responsible reporter will look through existing issues so they don't report 
> a duplicate and not necessarily leave a comment like "issue still valid." 
> If we close the issue automatically, what did that accomplish? I would 
> think triaging issues would be a good way for new team members to develop 
> their understanding of the site. If you're feeling unknowledgable about an 
> old issue, feel free to ping me for advice. I hope you might reconsider the 
> usefulness of the bot."
>
> It's six months later, and I'm now having to again comment on inactive 
> issues "stalebot, please don't close." to keep valid issues open.
>
> Paolo Melchiorre (author of this initiative) says, "activating the 
> stalebot last year allowed us to close many old issues. I think an issue 
> opened 7 years ago should be closed if no one takes care of it despite two 
> reminders in the last year. As the removal of the stalebot is not only up 
> to me, I think it is worth discussing it in a separate issue or on the 
> developer mailing list."
>
> I remain of the opinion that continued attempts to automatically abandon 
> valid issues are not helpful and do not reflect project maintenance best 
> practices. I would like to hear your thoughts on the matter. Thanks!
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0fbe194d-2626-49c6-a91e-b8538b0ae1a6n%40googlegroups.com.

Proposal: Constructing urls outside the request cycle

[Sarah Boyce]

Hello 👋 

This is a summary of some previous discussions which need opening up to the 
group 👍

There is a need to have some kind of URL outside the request cycle (such as 
sending emails which need to create a link).
For constructing a correct MEDIA_URL / STATIC_URL we wanted to use the 
script prefix to allow for more dynamic changes (ie allow a user to move to 
a subpath without having to change multiple variables). In the request 
cycle you can use get_script_prefix() for this but outside the request 
cycle this isn't currently very achievable (see related tickets #34028 
 #16734 
).

There is a current proposal from @Florian Apolloner:
"I am really starting to lean towards introducing a setting (yes!) called 
BASE_URL that can be set to https://mysite.com/subpath. This would allow 
for a) generating URLs outside a request context and b) allow us to mostly 
ignore script prefix. We could also use a relative STATIC_URL and append it 
to BASE_URL. This way there would be just one setting that requires 
changing and many projects hopefully would make that configurable via env 
vars etc."

New settings are a little controversial, so what do you think about this 
approach? Are there any other ideas or concerns?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/df82f370-e96a-498c-ac08-89d34d5cadd5n%40googlegroups.com.

Re: Stalebot on djangoproject.com issues

['Adam Johnson' via Django developers (Contributions to Django itself)]

I agree that we should remove Stalebot. Closing old issues doesn't fix them
or provide a reason why they aren’t going to be worked on.

On Thu, Apr 6, 2023 at 8:02 AM Sarah Boyce  wrote:

> From what it sounds, I guess the main value was prompting a one time
> spring clean. As there are not that many issues open in djangoproject.com
> and all issues will have been re-validated, I think it makes sense to
> remove it to reduce this additional burden/frustration.
>
> There are configurations around stale PR closing which I think makes more
> sense in general (maybe not for djangoproject.com as there are not many
> PRs), as other people might be reluctant to work on something if there is
> an open PR and it prompts someone to decide if they want to come back to
> this if they have just forgotten for example.
>
> On Wednesday, 5 April 2023 at 23:30:54 UTC+2 Tim Graham wrote:
>
>> Hello,
>>
>> In October 2022, a stalebot was activated for djangoproject.com issues:
>>
>> https://github.com/django/djangoproject.com/issues/1219
>> https://github.com/django/djangoproject.com/pull/1220
>>
>> It comments on an issue if there's no activity in the last six months: "This
>> issue has been automatically marked as stale because it has not had recent
>> activity. It will be closed if no further activity occurs. Thank you for
>> your contributions."
>>
>> The bot closes the issue if there's no activity in the next seven days.
>>
>> I didn't see much discussion among the djangproject.com team outside of
>> the issue and PR,  but the rationale from the issue is this: "Idea
>> copied from DRF PR #8423
>>  - Add a
>> StaleBot, configured with the lowest possible run limit. The intent here
>> is to help us sweep through the issue and pull request backlog, and review
>> what does and does not need to remain open at this point in time."
>>
>> Here is what I said at the time: "I think this is a lame way to handle
>> old issues. The result seems to be Carlton triaging all issues that the bot
>> comments on. You could have asked him to do that without a bot adding
>> noise. Should a useless "issue still valid" comment be required every 180
>> days? Why not have a human triage each issue now that more people are
>> maintaining this site? Using a bot comes off to me as passive aggressive.
>> Why try to automatically discard years of issues (even if minor)? It's not
>> like the passage of time or lack of activity means the problem went away. A
>> responsible reporter will look through existing issues so they don't report
>> a duplicate and not necessarily leave a comment like "issue still valid."
>> If we close the issue automatically, what did that accomplish? I would
>> think triaging issues would be a good way for new team members to develop
>> their understanding of the site. If you're feeling unknowledgable about an
>> old issue, feel free to ping me for advice. I hope you might reconsider the
>> usefulness of the bot."
>>
>> It's six months later, and I'm now having to again comment on inactive
>> issues "stalebot, please don't close." to keep valid issues open.
>>
>> Paolo Melchiorre (author of this initiative) says, "activating the
>> stalebot last year allowed us to close many old issues. I think an issue
>> opened 7 years ago should be closed if no one takes care of it despite two
>> reminders in the last year. As the removal of the stalebot is not only up
>> to me, I think it is worth discussing it in a separate issue or on the
>> developer mailing list."
>>
>> I remain of the opinion that continued attempts to automatically abandon
>> valid issues are not helpful and do not reflect project maintenance best
>> practices. I would like to hear your thoughts on the matter. Thanks!
>>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/0fbe194d-2626-49c6-a91e-b8538b0ae1a6n%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0%2Bv4-d0-bvTQNZE0HAUONRoE0U4Qcyt2zFAhxBXMAidw%40mail.gmail.com.

Re: Implement Ruff Linter

['Adam Johnson' via Django developers (Contributions to Django itself)]

I don't think we should adopt Ruff. It's a new, somewhat experimental
project. It wouldn't provide any gains except speed, but that is not really
a concern since it still takes a handful of seconds to lint Django with
Flake8 and co.

On Mon, Apr 3, 2023 at 1:59 PM Jerome Obi  wrote:

> Hi !
> I use Ruff as my primary Linter for all my Python Projects.
> https://github.com/charliermarsh/ruff
>
> It's very fast and powerful, so I thought I could try it on Django Code.
> With all options activated, Django is scanned in less than 1 second.
> Here's the Configuration with all detected errors types ignored.
> https://github.com/django/django/compare/main...obi-jerome:django:Ruff
>
> What do you think ?
> Is it done the proper way ?
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/c3201044-4d25-49d3-b0ce-06de4c7624efn%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0RyJPoZKz5o4LCYwe4FabcR197%2BiC19NZPoHBU3SAw2Q%40mail.gmail.com.

Re: Proposal: Check constraints at the model field level

[charettes]

Small clarification here.

> it should be noted that SQL has both CHECK on the field and table level,

>From my understanding CREATE TABLE / ADD COLUMN checks on the field level 
are really just syntactic sugar for checks at the table level like just 
like `REFERENCES` usage is syntactic sugar for foreign key constraints.

> This is not true for unique constraints or indices.

Unique constraints can be defined using the UNIQUE keyword just like CHECK 
is used to define a check per field, it's really just a different way of 
defining that a unique constraint on a field must be created.

The question of whether or not we want to provide some Django syntactic 
sugar in the form of `Field.check` and the benefits it might provide to 
third-parties (and even ourselves for dog fooding PositiveIntegerField) 
remains but I think that it's important to point out that there's no 
distinction between field and table level constraints at the database level 
AFAIK (for Postgres and SQLite at least).

Simon
Le jeudi 6 avril 2023 à 01:47:48 UTC-4, Adam Johnson a écrit :

> Mariusz, I agree with the burden, but it should be noted that SQL has both 
> CHECK on the field and table level, and CheckConstraint only defines 
> table-level constraints. This is not true for unique constraints or indices.
>
> Also, what do you think of a way for custom field classes to add 
> constraints, at least? db_check() is somewhat limiting given it must return 
> raw SQL, plus it's undocumented.
>
> On Thu, Apr 6, 2023 at 5:11 AM Mariusz Felisiak  
> wrote:
>
>> Hi,
>>
>> This proposal is not really nice from a maintenance point of view as we 
>> will end with the same complicated situation we currently have with 
>> uniqueness checks or indexes i.e. many ways to define the same:
>>
>> - Field.unique/index
>> - Meta.unique_together/index_together
>> - Meta.constraints/indexes
>>
>> It's especially error-prone in migrations and different database behavior 
>> on fields already covered by the same constraints/indexes. I'm pretty sure 
>> that we've introduced Meta.contraints/indexes to avoid this happening in 
>> the future, and we are rather leaning to leave only 
>> Meta.constraints/indexes and remove other options in the future. Not 
>> creating a new one.
>>
>> Initial -1 from me.
>>
>> Best,
>> Mariusz
>>
>> -- 
>>
> 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-develop...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/954af838-2176-4877-b4ac-70525cddcbf5n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/58ab388c-2852-4e23-94b9-c4f7d9fa61bfn%40googlegroups.com.

Re: Implement Ruff Linter

[charettes]

Strong agree with Adam here.

If Ruff current offer is enhanced speed at the cost of a less mature 
ecosystem I don't think that it's a tradeoff Django should make at the time 
being.

Simon

Le jeudi 6 avril 2023 à 08:16:00 UTC-4, Adam Johnson a écrit :

> I don't think we should adopt Ruff. It's a new, somewhat experimental 
> project. It wouldn't provide any gains except speed, but that is not really 
> a concern since it still takes a handful of seconds to lint Django with 
> Flake8 and co.
>
> On Mon, Apr 3, 2023 at 1:59 PM Jerome Obi  wrote:
>
>> Hi !
>> I use Ruff as my primary Linter for all my Python Projects.
>> https://github.com/charliermarsh/ruff
>>
>> It's very fast and powerful, so I thought I could try it on Django Code.
>> With all options activated, Django is scanned in less than 1 second.
>> Here's the Configuration with all detected errors types ignored.
>> https://github.com/django/django/compare/main...obi-jerome:django:Ruff
>>
>> What do you think ?
>> Is it done the proper way ?
>>
>> -- 
>> 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-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/c3201044-4d25-49d3-b0ce-06de4c7624efn%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6758f3a6-8b89-4a5b-8186-1935ea00f92en%40googlegroups.com.

Django "makemigrations -- update" donot working

[Saifullah Shahen]

in my custom user model, initially, my model looks like this

class User(AbstractUser, BaseModelWithUUID):
phone = models.CharField(max_length=11, 
validators=[validate_phone_number])
I do command "makemigrations" which create a initial migration file

but after updating my model like this

class User(AbstractUser, BaseModelWithUUID):
phone = models.CharField(max_length=11, 
validators=[validate_phone_number])
name = models.CharField(max_length=255)

after adding a field "name" when i run "makemigrations --update" it shows a 
error:

CommandError: Cannot update applied migration 'authentication.0001_initial'.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/793fee18-1231-456b-8d91-f976bebad5e2n%40googlegroups.com.