RFC: support recursive path pattern delegations
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Área
- documentation
Línea de trabajo
Comienza revisando la semántica existente de PATHPATTERN y cómo se representa spec_version en root.json. Compara la coincidencia recursiva ** propuesta con la alternativa de prefijo de ruta y, después, define el comportamiento de control de versiones; se considera terminado cuando la especificación ha decidido un enfoque y describe claramente sus reglas de compatibilidad.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
At the moment, the wildcards supported by PATHPATTERN only allow you to match within one directory, but this is quite problematic if you want to delegate entire directory trees to a role. A fairly simple example where this would be particularly useful is if you use directories to represent projects which can then delegate to sub-projects -- the top-level delegator role would not know how the delegatee's structure looks in order to create a comprehensive PATHPATTERN, but all they would care about is the top-level directory.
The simplest proposal that matches the existing Unix glob-like semantics would be to allow for ** to act as a wildcard that matches / as well (many Unix tools support that as a special kind of glob). An alternative approach would be to allow for a PATHPATTERN to define a path prefix to match against, but ** is more generic.
Regardless of the approach taken, clients would likely need to gate this new matching behaviour based on the spec_version in root.json as otherwise they may start to misinterpret older repository data that inadvertently used ** instead of * for regular globbing.
- Lenguaje dominante
- Python
- Estrellas
- 405
- Forks
- 59
- Merge medio
- 3 d 4 h
- PR fusionados (30 d)
- 1
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
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 theupdateframework/specification
-
Two definitions of KEYIDAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
theupdateframework/specification#323 · 1 reacción ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
theupdateframework/specification#321 · 6 comentarios ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
theupdateframework/specification#312 · 25 comentarios · 4 reacciones ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 28/100
theupdateframework/specification#310 · 1 comentario · 2 reacciones ·
Todos los issues de theupdateframework/specification
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
PedestrianDynamics/pyFDS-Evac#343 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
theskumar/python-dotenv#708 ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
Los mantenedores suelen responder en 2 días
-
Docs Timedelta
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
pandas-dev/pandas#69919 ·
Los mantenedores suelen responder en 1 día
-
API documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
zephyrproject-rtos/west#1009 · 2 comentarios ·
Los mantenedores suelen responder en 3 días