Upload history should be qualified as cache data
Los mantenedores suelen responder en 3 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 35/100
Línea de trabajo
Comienza en mapillary_tools/upload.py, en las líneas 50-55, y compara el valor predeterminado actual del historial de cargas con appdirs.user_cache_dir. El trabajo estará terminado cuando la ubicación predeterminada del historial use el directorio de caché del usuario, mientras MAPILLARY_UPLOAD_HISTORY_PATH siga siendo una opción de anulación para quienes quieran un comportamiento diferente de retención o compartición.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
https://github.com/mapillary/mapillary_tools/blob/2f3331c6194a9d977e2e06541320830feb9ac7ad/mapillary_tools/upload.py#L50-L55
This data is not essential for the app to work. It is neither an app setting, a configuration, nor a preference. It can also be recreated at any time. The upload history is not tied to a specific machine either because uploaded imagery could have been pulled by the local machine from anywhere. Thus, it should not need to roam. The upload history can become huge very quickly for users frequently uploading lots of sequences. No one really wants to roam this stuff around over networks. Furthermore, for how long does this “history” (has to) live?
Please, see the XDG Base Directory Specification for qualifying app data. The same logic applies to basically any other OS. So please, use appdirs.user_cache_dir for upload history data. Yeah, you can override MAPILLARY_UPLOAD_HISTORY_PATH but it should be set to a sane default initially. If a user really wants to keep track of uploaded sequences over multiple machines or wants to keep the upload history indefinitely then they should configure MAPILLARY_UPLOAD_HISTORY_PATH to their desire.
- Lenguaje dominante
- Python
- Estrellas
- 316
- Forks
- 144
- Merge medio
- 2 d 1 h
- PR fusionados (30 d)
- 2
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin 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 mapillary/mapillary_tools
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 45/100
mapillary/mapillary_tools#844 ·
Los mantenedores suelen responder en 3 días
-
Dificultad 3/5 1-2 días Aptitud para principiantes 48/100
mapillary/mapillary_tools#827 ·
Los mantenedores suelen responder en 3 días
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
mapillary/mapillary_tools#819 · 2 comentarios ·
Los mantenedores suelen responder en 3 días
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
mapillary/mapillary_tools#783 · 3 comentarios ·
Los mantenedores suelen responder en 3 días
-
Dificultad 4/5 3-5 días Aptitud para principiantes 38/100
mapillary/mapillary_tools#748 · 2 comentarios ·
Los mantenedores suelen responder en 3 días
Todos los issues de mapillary/mapillary_tools
Issues similares
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 88/100
gradio-app/gradio#13964 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 93/100
BSData/horus-heresy-3rd-edition#3232 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
jbacalso24/mimry#123 ·
Los mantenedores suelen responder en 1 día
-
p:3-mid pydanty:bug pydanty:is-working
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
pydantic/pydantic-ai#10153 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
good first issue priority: medium size: S testing
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
cubrid-lab/cubrid-cookbook-python#316 ·
Los mantenedores suelen responder en 1 día