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 th
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,
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 A
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, Ja
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 squas
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 developer
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$||;
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._prefet
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
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
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 s
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
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 f
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
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 Googl
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
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 seem
17 matches
Mail list logo
