Models in a sub-package of an app get the sub-package's label (`io_storages/s3/models.py` → app `s3`)
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- Medio día
- Aptitud para principiantes
- 78/100
Línea de trabajo
The app label is set inline in parse_models_file() in cli/orm_lens/parser.py (around lines 610-614), and the same rule lives in _app_dir_for() in cli/orm_lens/_paths.py. Start by reproducing the io_storages/s3/models.py layout and running orm-lens list and drift, then look at how both call sites derive the app. Done means list shows io_storages.S3ImportStorage, drift reports nothing, the existing shop/ cases keep their labels, and cd cli && python -m pytest -q passes.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Source: label-studio — label_studio/io_storages/{s3,gcs,azure_blob,redis,localfiles}/models.py
What happens
The app label comes from the directory that holds models.py (or from the parent of a models/ package). That breaks for apps that split models into sub-packages:
io_storages/
apps.py
migrations/
models.py # from .s3.models import S3ImportStorage
s3/models.py # class S3ImportStorage(models.Model)
Django puts S3ImportStorage in io_storages: the label comes from the app config whose package contains the module, not from the file's own directory. orm-lens calls the app s3.
On label-studio list shows s3.S3ImportStorage, gcs.GCSImportStorage and so on, describe io_storages.S3ImportStorage fails, and drift prints 25 "migrated, but models.py does not declare it" lines for io_storages.*.
Repro
io_storages/__init__.py, io_storages/migrations/__init__.py, io_storages/s3/__init__.py: empty.
io_storages/models.py
from .s3.models import S3ImportStorage # noqa: F401
io_storages/s3/models.py
from django.db import models
class S3ImportStorage(models.Model):
bucket = models.TextField(null=True, blank=True)
prefix = models.TextField(null=True, blank=True)
io_storages/migrations/0001_initial.py
from django.db import migrations, models
class Migration(migrations.Migration):
initial = True
dependencies = []
operations = [
migrations.CreateModel(
name="S3ImportStorage",
fields=[
("id", models.AutoField(primary_key=True, serialize=False)),
("bucket", models.TextField(null=True, blank=True)),
("prefix", models.TextField(null=True, blank=True)),
],
),
]
$ orm-lens list
s3.S3ImportStorage
$ orm-lens describe io_storages.S3ImportStorage
error: model 'io_storages.S3ImportStorage' not found
$ orm-lens drift
~ io_storages.s3importstorage: migrated, but models.py does not declare it
stale table, or the model lives outside the parsed tree
summary: 1 model(s) drifted, 0 blocking, 1 migration(s) replayed
Expected: io_storages.S3ImportStorage, no drift.
Where
cli/orm_lens/parser.py, lines 610–614 inparse_models_file()(line 498): setsapp_namefrom the parent directory, or the grandparent formodels/.cli/orm_lens/_paths.py, line 21,_app_dir_for(): the same rule, used to group models into apps (parser.py:1191) and to pick a base class in the same app (parser.py:826). Both have to agree.
Suggested fix
Put the lookup in _app_dir_for() and use it from parse_models_file() too, instead of the inline copy:
- Start at the directory of the file (or the parent of a
models/package, as now). - If that directory has
migrations/orapps.py, it's the app. - Otherwise go up while the parent is still a package (has
__init__.py) and stop at the first directory that hasmigrations/orapps.py. - Nothing found: today's rule.
The __init__.py check keeps the walk inside the project. Meta.app_label is a separate case, leave it out.
src/parser.ts has the same rule (around lines 380 and 632). A Python-only fix is fine, leave a note in the PR for the TS side.
How to test
- A new test with the repro:
listgivesio_storages.S3ImportStorage,driftreports nothing. - A plain app (
shop/models.py) and amodels/package (shop/models/order.py) keep their labels. - A
models.pyin a folder with nomigrations/orapps.pyabove it keeps today's label. - Run the golden snapshots. If a project changes, update it and list the changes in the PR.
cd cli && python -m pytest -q,ruffandmypypass.
Difficulty: good first issue, one helper and a few tests.
- Lenguaje dominante
- Python
- Estrellas
- 84
- Forks
- 13
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de FROWNINGdev/django-orm-lens
-
suggest-indexes proposes composite indexes that include the primary key or a unique fieldPosiblemente ocupada @bfs2021 la tomó hoy. Abiertobug good first issue python
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
FROWNINGdev/django-orm-lens#269 ·
-
`migration-risk` text output prints `app.None` for graph-level findingsPosiblemente ocupada @phoenixbycaselka la tomó hoy. Abiertobug good first issue python
Dificultad 1/5 1-3 horas Aptitud para principiantes 88/100
FROWNINGdev/django-orm-lens#268 ·
-
Finish the Chinese rule reference — DOL001–DOL007Quizá libre de nuevo @harbinresearcher la tomó hace 64 días y no hay ningún pull request abierto. Abiertodocumentation good first issue help wanted
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
FROWNINGdev/django-orm-lens#81 · 2 comentarios ·
-
Fields inherited from Django's `AbstractBaseUser` / `PermissionsMixin` / `AbstractUser` are missingAbiertobug good first issue python
Dificultad 3/5 1-2 días Aptitud para principiantes 62/100
FROWNINGdev/django-orm-lens#267 ·
-
enhancement help wanted python
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
FROWNINGdev/django-orm-lens#254 ·
Todos los issues de FROWNINGdev/django-orm-lens
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
gorakhargosh/watchdog#1462 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
openwisp/openwisp-monitoring#889 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
OpenFreeEnergy/Lomap#180 ·
-
generate_observation_scenario_from_cpgs exposure time conversion when auto-gain set to 'yes'Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
roman-corgi/corgisim#327 ·
Los mantenedores suelen responder en 2 días
-
agent:WSL bug code-review linux pri:medium sev:low tooling
Dificultad 2/5 Medio día Aptitud para principiantes 62/100
Los mantenedores suelen responder en 1 día