How terrible would something like this be:
class AppConfig:
"""Class representing a Django application and its configuration."""
.
@cached_property
def is_squashable(self):
if hasattr(self, 'squashable'):
return self.squashable
code from isort
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
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
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,
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
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
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
>
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
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
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
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
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
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
I definitely think this is worth pursuing - the reason I didn't do it back
in the day was that squashing the entire project involved solving some
rather nasty dependency graph issues if there were any cycles of apps
depending on models from other apps.
If we can overcome that, though, and squash
This comes from a place of headaches: we're a large team, and our sprint
are a month long, in that month we generate a lot of migrations, after a
couple of sprints we see our tests take a real toll when running
migrations, this is due to constantly adding columns/deleting columns,
moving data
17 matches
Mail list logo
