Custom GROUP BY method. OLAP functionality.

[Mads Jensen]

Hello,

I started this rather messy draft (outline of how I think it could be 
approached), as I posted this ticket [1] some years ago. 
Basically, SQL adds some modifiers to group the result set in different ways. 
The ticket contains some links with good examples.

In order to solve this, it seems necessary to make a method that bypasses the 
group by logic of Django, so expert users can 
handle this themselves. Most likely, users who want to use this feature, are 
already more familiar with how a database works, 
than Django deals with GROUP BY quite well, so the name may be poorly chosen, 
because seasoned 
database people starting off with Django may be tempted to neglect this fact, 
and jump straight off to that method, not reading 
the admonition.

There's already get_group_by_cols which may be considered as well. I left a 
flag in the draft, Query.custom_group_by but haven't 
thought this through.

I think it should be manageable for me to work on getting subquery (I posted 
another thread 2-3 weeks ago) and a custom grouping 
method introduced in Django 3.2.

[1] https://code.djangoproject.com/ticket/27646
--
Med venlig hilsen / Kind regards,
Mads Jensen


-- 
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/A6DC48D3554543B2BC0DBB8D175F90A7.MAI%40webhot.dk.

Re: [FEATURE] Allow squashmigrations to squash the whole project

[Adam Johnson]

One concern here is to avoid squashing third party apps' migrations. Django
doesn't currently distinguish between third party and project apps. It
might be possible to use the heuristic "is site-packages in the apps'
module's absolute path?" But this is not 100%  accurate since third party
packages can be installed other ways.

On Wed, 22 Apr 2020 at 18:50, Javier Buzzi  wrote:

> Sounds great Andrew, i'm going to say this up front:
>
> 1. You're awesome, thank you for making south and migrations.
> 2. I'm inevitably need your help on this one, there were a lot of hacks I
> did because I couldn't come up with a better way. I'll get started, as a v1
> to just port all the work done from the other project, and from there I
> will REALLY welcome your insight, guidance, and specially your criticism.
>
> Thank you!
> Javier Buzzi
>
> --
> 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/220584c4-a0bc-4535-906e-f120b7080add%40googlegroups.com
> 
> .
>


-- 
Adam

-- 
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/CAMyDDM3CcZqv1Oi98seRvfGjc8aiLPm_igAsNa2%3DTg%2B8D5ZUmQ%40mail.gmail.com.

Re: [FEATURE] Allow squashmigrations to squash the whole project

[Javier Buzzi]

Correct. Im adding that functionality currently -- im taking the VERY naive 
approach of looking at BASE_DIR and if the app is not in there, its foreign 
to the project. Some insight or better ideas to this would be appreciated.

-- 
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/f202a4bb-1d7b-4c85-9695-f4ef3b996c3c%40googlegroups.com.

Re: [FEATURE] Allow squashmigrations to squash the whole project

[Adam Johnson]

That's good, but unfortunately BASE_DIR is only a "pseudo setting." It's
something in the startproject template that's useful for building file
paths but nothing inside Django actually relies on it or checks that it's
set. Perhaps we should consider "promoting" it to a real setting though, to
make this easier. Still, that might be naive for projects that bundle their
dependencies in some way :/

(Slightly tangential - my post on BASE_DIR and its move to pathlib in 3.1:
https://adamj.eu/tech/2020/03/16/use-pathlib-in-your-django-project/ )

On Tue, 28 Apr 2020 at 13:36, Javier Buzzi  wrote:

> Correct. Im adding that functionality currently -- im taking the VERY
> naive approach of looking at BASE_DIR and if the app is not in there, its
> foreign to the project. Some insight or better ideas to this would be
> appreciated.
>
> --
> 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/f202a4bb-1d7b-4c85-9695-f4ef3b996c3c%40googlegroups.com
> 
> .
>


-- 
Adam

-- 
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/CAMyDDM2%3DSTi9pe3LyaYL4%2BLEu8ZcWCgcjynR5MvV30PJiTsoDQ%40mail.gmail.com.

Re: Hashing Session Keys in backends

[mark]

Initial (draft) Pull Request: https://github.com/django/django/pull/12814 

The pull request at the very least still needs documentation, but would be 
good to have a review of the implementation first.




On Thursday, April 23, 2020 at 11:22:39 AM UTC+2, mark wrote:
>
> Hey Adam, thanks for the feedback, I'll make sure to credit Chris' 
> original work in a new PR, I think I'm getting close to having one ready.
>
> Is there a way to avoid breaking third party backends, but raising 
>> deprecation warnings?
>>
>  
> I could create a new SessionBase child class (something like 
> *HashingSessionBase*) and make all the default backends inherit from this 
> class, instead of from *SessionBase* directly. Any sessions backend that 
> does not inherit from the new *HashingSessionBase* could then be 
> nominated for deprecation. This will also allow making no/minimal changes 
> to the *SessionBase* class to optimise backward compatibility.
>
>
>  
>
> On Wednesday, April 15, 2020 at 1:41:00 AM UTC+2, Adam Johnson wrote:
>>
>> Hi Mark
>>
>> Thanks for looking into this tricky security issue.
>>
>> I'm suggesting to use the names frontend_key and backend_key for these 
>>> two concepts.
>>>
>>
>> They seem reasonable to me, as long as there's an explanatory comment. 
>> Perhaps it even needs documenting for third party backends.
>>
>> My second suggestion is to refactor the SessionBase class to make sure 
>>> the session-key-hashing happens in one place and isn't spread across all 
>>> different backend implementations as is the case now because the subclasses 
>>> have to implemented public methods that receive the frontend_key.
>>>
>>
>> Yes that seems reasonable, although I haven't looked closely. Is there a 
>> way to avoid breaking third party backends, but raising deprecation 
>> warnings? Perhaps using func_supports_parameter 
>> 
>>  
>> or similar that we've used in past deprecations?
>>
>> I see the PR is quite old and not owned by you. If you want to open a new 
>> PR, rebase the existing code, and refactor it as you see fit, you can use 
>> Co-Authored-By 
>>  to 
>> acknowledge Chris' original work.
>>
>> Thanks,
>>
>> Adam
>>
>> On Fri, 10 Apr 2020 at 10:41, mark  wrote:
>>
>>> After renewed interest because of potential database timing attacks (
>>> T31412 ) I'm looking into 
>>> an existing PR (PR8736  for 
>>> T21076 ) for adding the 
>>> possibility of storing hashes of session keys.
>>>
>>> I'm looking to get some feedback on two things;
>>>
>>> After going through the existing commits of Chris Griffin, I agree with 
>>> Aymeric Augustin (who did an initial review of the pull request) that there 
>>> should be a clearer distinction between the incoming session key (Aymeric 
>>> talks about a "clear text session key") and the key that gets stored in the 
>>> sessions backend (Aymeric talks about a "hashed if needed session key").
>>> I'm suggesting 
>>>  to 
>>> use the names *frontend_key* and *backend_key* for these two concepts.
>>>
>>> My second suggestion 
>>>  is 
>>> to refactor the *SessionBase* class to make sure the 
>>> session-key-hashing happens in one place and isn't spread across all 
>>> different backend implementations as is the case now because the subclasses 
>>> have to implemented public methods that receive the frontend_key. I'm 
>>> suggesting to basically have subclasses implement private methods that 
>>> receive a backend_key, which will be invoked by the public methods in the 
>>> BaseClass. Obviously this will have consequences for any existing custom 
>>> backends out there, though I think those will be affected either way. 
>>>
>>> I welcome any thoughts on both the naming convention and the refactoring.
>>>
>>> -- 
>>> 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-d...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/41c26919-f15f-4151-aa82-1281e24656da%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>
>>
>> -- 
>> Adam
>>
>

-- 
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 emai

Re: [FEATURE] Allow squashmigrations to squash the whole project

[Markus Holtermann]

Have you considered to allow for multiple app_labels in the `squashmigrations` 
command, maybe together with a `--cross-app` flag, to specify the apps from 
which migrations should be squashed? That way we don't need to rely on paths at 
all, but can log up all migrations in question, based on the provided app 
labels.

Cheers,

Markus

On Tue, Apr 28, 2020, at 2:47 PM, Adam Johnson wrote:
> That's good, but unfortunately BASE_DIR is only a "pseudo setting." 
> It's something in the startproject template that's useful for building 
> file paths but nothing inside Django actually relies on it or checks 
> that it's set. Perhaps we should consider "promoting" it to a real 
> setting though, to make this easier. Still, that might be naive for 
> projects that bundle their dependencies in some way :/
> 
> (Slightly tangential - my post on BASE_DIR and its move to pathlib in 
> 3.1: 
> https://adamj.eu/tech/2020/03/16/use-pathlib-in-your-django-project/ )
> 
> On Tue, 28 Apr 2020 at 13:36, Javier Buzzi  wrote:
> > Correct. Im adding that functionality currently -- im taking the VERY naive 
> > approach of looking at BASE_DIR and if the app is not in there, its foreign 
> > to the project. Some insight or better ideas to this would be appreciated.
> 
> >  -- 
> >  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/f202a4bb-1d7b-4c85-9695-f4ef3b996c3c%40googlegroups.com
> >  
> > .
> 
> 
> -- 
> Adam
> 
>  -- 
>  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/CAMyDDM2%3DSTi9pe3LyaYL4%2BLEu8ZcWCgcjynR5MvV30PJiTsoDQ%40mail.gmail.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/eaa8b320-15b9-43ab-b50c-3bb6a704898f%40www.fastmail.com.

Re: [FEATURE] Allow squashmigrations to squash the whole project

[Adam Johnson]

That's a good suggestion Markus, and more flexible.

On Tue, 28 Apr 2020 at 16:40, Markus Holtermann 
wrote:

> Have you considered to allow for multiple app_labels in the
> `squashmigrations` command, maybe together with a `--cross-app` flag, to
> specify the apps from which migrations should be squashed? That way we
> don't need to rely on paths at all, but can log up all migrations in
> question, based on the provided app labels.
>
> Cheers,
>
> Markus
>
> On Tue, Apr 28, 2020, at 2:47 PM, Adam Johnson wrote:
> > That's good, but unfortunately BASE_DIR is only a "pseudo setting."
> > It's something in the startproject template that's useful for building
> > file paths but nothing inside Django actually relies on it or checks
> > that it's set. Perhaps we should consider "promoting" it to a real
> > setting though, to make this easier. Still, that might be naive for
> > projects that bundle their dependencies in some way :/
> >
> > (Slightly tangential - my post on BASE_DIR and its move to pathlib in
> > 3.1:
> > https://adamj.eu/tech/2020/03/16/use-pathlib-in-your-django-project/ )
> >
> > On Tue, 28 Apr 2020 at 13:36, Javier Buzzi 
> wrote:
> > > Correct. Im adding that functionality currently -- im taking the VERY
> naive approach of looking at BASE_DIR and if the app is not in there, its
> foreign to the project. Some insight or better ideas to this would be
> appreciated.
> >
> > >  --
> > >  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/f202a4bb-1d7b-4c85-9695-f4ef3b996c3c%40googlegroups.com
> <
> https://groups.google.com/d/msgid/django-developers/f202a4bb-1d7b-4c85-9695-f4ef3b996c3c%40googlegroups.com?utm_medium=email&utm_source=footer
> >.
> >
> >
> > --
> > Adam
> >
> >  --
> >  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/CAMyDDM2%3DSTi9pe3LyaYL4%2BLEu8ZcWCgcjynR5MvV30PJiTsoDQ%40mail.gmail.com
> <
> https://groups.google.com/d/msgid/django-developers/CAMyDDM2%3DSTi9pe3LyaYL4%2BLEu8ZcWCgcjynR5MvV30PJiTsoDQ%40mail.gmail.com?utm_medium=email&utm_source=footer
> >.
>
> --
> 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/eaa8b320-15b9-43ab-b50c-3bb6a704898f%40www.fastmail.com
> .
>


-- 
Adam

-- 
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/CAMyDDM0sCtAW1%2Bv8GOqW1D3X89eVzremBRrz-vB%2BbNqV%2BDJ99w%40mail.gmail.com.

Re: [FEATURE] Allow squashmigrations to squash the whole project

[Javier Buzzi]

And then do?

$ ./manage.py squashmigrations --crossapp=$(find . -name apps.py | sed 
's|/apps.py$||; s|^./||; s|/|.|g' | xargs printf '%s,')

We have 54 apps currently.. more to come. I'm sure there are projects out 
there with more, this can get frighting, specially for windows users -- not 
sure what the equivalent powershell/batch command is -- do they have 
limitations in terms of command length? Perhaps I'm only looking at this 
from my narrow point of view where we squash constantly, every app after 
each release, maybe this is not for everyone. If you guys think this is the 
way to go, let's do that then.

-- 
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/301d4b7c-1023-41fc-b2f2-89676ee8febe%40googlegroups.com.

queryset.iterator() and prefetch_related()

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

Hi all,

I notice a piece of code inside ModelChoiceIterator that seems to keep going a 
bit back and forth, currently it looks like this:

# Can't use iterator() when queryset uses prefetch_related()
if not queryset._prefetch_related_lookups:
queryset = queryset.iterator()

But before it looked like this:

# Can't use iterator() when queryset uses prefetch_related()
if not queryset._prefetch_related_lookups and queryset._result_cache is 
None:
 queryset = queryset.iterator()

Anyway, my issue is that it forces 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/GsH5_PynvlvfvUOGXdykXjO56LubTE6KuNzKjLZpnn2SX_AqPJ5Y43DbelaKtV8AiTEJBl5OETUjhJ6etgiBQGP9-koYrM2LOlVhG4Om6Yc%3D%40protonmail.com.

Re: queryset.iterator() and prefetch_related()

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

Sorry I sent the mail prior to finishing, redoing fully from here:

I notice a piece of code inside ModelChoiceIterator that seems to keep going a 
bit back and forth, currently it looks like this:

# Can't use iterator() when queryset uses prefetch_related()
if not queryset._prefetch_related_lookups:
queryset = queryset.iterator()

But before it looked like this:

# Can't use iterator() when queryset uses prefetch_related()
if not queryset._prefetch_related_lookups and queryset._result_cache is 
None:
 queryset = queryset.iterator()

Anyway, if you want to implement your own QuerySet class from scratch, which is 
the case of django-querysetsequence, and that's pretty useful to feed 
ModelChoiceFields, as long as you prefix object ids with content type ids which 
is pretty trivial.

Do you think it would be acceptable to start an effort with the objective of 
making django.forms.models rely purely on a public API of QuerySet ?

In this case, how would you accept to see that changed ?

Thanks in advance

Have a great day

-- 
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/8s1A9w1r5BtgXJCoWjwInlAzC5cQeYV3LWjFnGxcz-1qcMSxGyjAz6mdpUxmnB3wveLORpXmMcPjwVk-o_SbzTjy6ZMkbkn89qCH_i2S4n8%3D%40protonmail.com.

Re: [FEATURE] Allow squashmigrations to squash the whole project

[charettes]

I guess we could allow an "__all__" or "all" sentinel to mean _all apps_ 
like we use "zero" to revert the initial migration.

Le mardi 28 avril 2020 12:16:23 UTC-4, Javier Buzzi a écrit :
>
> And then do?
>
> $ ./manage.py squashmigrations --crossapp=$(find . -name apps.py | sed 
> 's|/apps.py$||; s|^./||; s|/|.|g' | xargs printf '%s,')
>
> We have 54 apps currently.. more to come. I'm sure there are projects out 
> there with more, this can get frighting, specially for windows users -- not 
> sure what the equivalent powershell/batch command is -- do they have 
> limitations in terms of command length? Perhaps I'm only looking at this 
> from my narrow point of view where we squash constantly, every app after 
> each release, maybe this is not for everyone. If you guys think this is the 
> way to go, let's do that then.
>

-- 
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/9c10cb75-7949-4005-955b-e7eaa24dc5d2%40googlegroups.com.

Re: [FEATURE] Allow squashmigrations to squash the whole project

[Javier Buzzi]

To do that we need to know which apps are part of your project, and which 
are not. Otherwise you'll be squashing "django.contrib.auth" as an example, 
and you're not going to have a fun time at that..

-- 
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/3cd4db15-c4b0-416f-8c51-2f67610a37c8%40googlegroups.com.

Re: [FEATURE] Allow squashmigrations to squash the whole project

[charettes]

Don't we need to prevent that from happening anyway? I guess we'd want to 
prevent --crossapp=auth from working as well.

Le mardi 28 avril 2020 13:50:54 UTC-4, Javier Buzzi a écrit :
>
> To do that we need to know which apps are part of your project, and which 
> are not. Otherwise you'll be squashing "django.contrib.auth" as an example, 
> and you're not going to have a fun time at that..
>

-- 
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/ca814e82-9258-40eb-afed-82edb0bc29c8%40googlegroups.com.

Re: [FEATURE] Allow squashmigrations to squash the whole project

[Javier Buzzi]

To be kind to the user, absolutely! .. any idea on how to implement it O:)

> On Apr 28, 2020, at 2:29 PM, charettes  wrote:
> 
> Don't we need to prevent that from happening anyway? I guess we'd want to 
> prevent --crossapp=auth from working as well.
> 
> Le mardi 28 avril 2020 13:50:54 UTC-4, Javier Buzzi a écrit :
> To do that we need to know which apps are part of your project, and which are 
> not. Otherwise you'll be squashing "django.contrib.auth" as an example, and 
> you're not going to have a fun time at that..
> 
> -- 
> 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/ca814e82-9258-40eb-afed-82edb0bc29c8%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/DB50F1F6-6811-49C2-8937-584E8115932C%40gmail.com.

Re: [FEATURE] Allow squashmigrations to squash the whole project

[charettes]

It's notoriously hard to distinguish between first-party and third-party 
apps but I know some package manage to do it relatively well (e.g. isort).

Le mardi 28 avril 2020 14:32:13 UTC-4, Javier Buzzi a écrit :
>
> To be kind to the user, absolutely! .. any idea on how to implement it O:)
>
> On Apr 28, 2020, at 2:29 PM, charettes > 
> wrote:
>
> Don't we need to prevent that from happening anyway? I guess we'd want to 
> prevent --crossapp=auth from working as well.
>
> Le mardi 28 avril 2020 13:50:54 UTC-4, Javier Buzzi a écrit :
>>
>> To do that we need to know which apps are part of your project, and which 
>> are not. Otherwise you'll be squashing "django.contrib.auth" as an example, 
>> and you're not going to have a fun time at that..
>>
>
> -- 
> 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-d...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/ca814e82-9258-40eb-afed-82edb0bc29c8%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/8af08a8f-4f4d-4fef-8daa-e3743a1f8468%40googlegroups.com.

Re: [FEATURE] Allow squashmigrations to squash the whole project

[Markus Holtermann]

But for isort one specifies the `known_first_party` and `known_third_party` 
packages. https://github.com/timothycrosley/isort#configuring-isort

At least I was under the impression that that's the only way how it decides 
where to place imports.

Cheers,

Markus

On Tue, Apr 28, 2020, at 9:41 PM, charettes wrote:
> It's notoriously hard to distinguish between first-party and 
> third-party apps but I know some package manage to do it relatively 
> well (e.g. isort).
> 
> Le mardi 28 avril 2020 14:32:13 UTC-4, Javier Buzzi a écrit :
> > To be kind to the user, absolutely! .. any idea on how to implement it O:)
> > 
> >> On Apr 28, 2020, at 2:29 PM, charettes  wrote:
> >> 
> >> Don't we need to prevent that from happening anyway? I guess we'd want to 
> >> prevent --crossapp=auth from working as well.
> >> 
> >> Le mardi 28 avril 2020 13:50:54 UTC-4, Javier Buzzi a écrit :
> >>> To do that we need to know which apps are part of your project, and which 
> >>> are not. Otherwise you'll be squashing "django.contrib.auth" as an 
> >>> example, and you're not going to have a fun time at that..
> >> 
> >>  -- 
> >>  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-d...@googlegroups.com.
> >>  To view this discussion on the web visit 
> >> https://groups.google.com/d/msgid/django-developers/ca814e82-9258-40eb-afed-82edb0bc29c8%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/8af08a8f-4f4d-4fef-8daa-e3743a1f8468%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/3f95c379-9958-4ec9-8a14-aa0243f0ecb8%40www.fastmail.com.

Re: [FEATURE] Allow squashmigrations to squash the whole project

[charettes]

You don't have to explicitly configure them as long as you run isort within 
a Python environment that has all dependency installed properly. If you 
want to run isort without installing all of the deps of your package you 
have to explicitly specify which module is first or third party.

Here's the routine I was referring to 
https://github.com/timothycrosley/isort/blob/0ee43b6a4f3c40876c3c7714846ecf8e584dc314/isort/finders.py#L165-L191

Simon

Le mardi 28 avril 2020 16:04:14 UTC-4, Markus Holtermann a écrit :
>
> But for isort one specifies the `known_first_party` and 
> `known_third_party` packages. 
> https://github.com/timothycrosley/isort#configuring-isort 
>
> At least I was under the impression that that's the only way how it 
> decides where to place imports. 
>
> Cheers, 
>
> Markus 
>
> On Tue, Apr 28, 2020, at 9:41 PM, charettes wrote: 
> > It's notoriously hard to distinguish between first-party and 
> > third-party apps but I know some package manage to do it relatively 
> > well (e.g. isort). 
> > 
> > Le mardi 28 avril 2020 14:32:13 UTC-4, Javier Buzzi a écrit : 
> > > To be kind to the user, absolutely! .. any idea on how to implement it 
> O:) 
> > > 
> > >> On Apr 28, 2020, at 2:29 PM, charettes  wrote: 
> > >> 
> > >> Don't we need to prevent that from happening anyway? I guess we'd 
> want to prevent --crossapp=auth from working as well. 
> > >> 
> > >> Le mardi 28 avril 2020 13:50:54 UTC-4, Javier Buzzi a écrit : 
> > >>> To do that we need to know which apps are part of your project, and 
> which are not. Otherwise you'll be squashing "django.contrib.auth" as an 
> example, and you're not going to have a fun time at that.. 
> > >> 
> > >>  -- 
> > >>  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-d...@googlegroups.com. 
> > >>  To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/ca814e82-9258-40eb-afed-82edb0bc29c8%40googlegroups.com
>  
> <
> https://groups.google.com/d/msgid/django-developers/ca814e82-9258-40eb-afed-82edb0bc29c8%40googlegroups.com?utm_medium=email&utm_source=footer>.
>  
>
> > > 
> > 
> >  -- 
> >  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-d...@googlegroups.com . 
> >  To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/django-developers/8af08a8f-4f4d-4fef-8daa-e3743a1f8468%40googlegroups.com
>  
> <
> https://groups.google.com/d/msgid/django-developers/8af08a8f-4f4d-4fef-8daa-e3743a1f8468%40googlegroups.com?utm_medium=email&utm_source=footer>.
>  
>
>

-- 
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/2a1d8093-8447-4a1d-a434-53d03cc6680d%40googlegroups.com.