Refactor file format backend openers
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Refactoring
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- python
- Ambito
- backend, data-engineering
Direzione di ricerca
Inizia con l’API del backend per i formati di file nella documentazione di riferimento collegata, quindi leggi #375 e kerchunk/grib2.py per confrontare la forma di restituzione proposta di VirtualZarrStore e la gestione di GRIB. Il lavoro è completato quando l’interfaccia dell’opener e le regole per gli argomenti con nome sono state decise e vengono applicate in modo coerente, incluso un approccio concordato per i file GRIB.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Problem
The API for Kerchunk's file format backend openers doesn't follow a consistent pattern.
Suggestion
Change the openers to each be a function returning a VirtualZarrStore (see #375), with standardized keyword arguments.
Advantages
- Neater
- Can any common standardize keyword arguments
- Can do validation within file opening or immediately afterwards
- Would make it more obvious how to add a new opener for a new file type
- Could also allowing implementing a general file opener (like is done in pangeo-forge)
Implementation ideas
- Perhaps each opener should inherit from a single abstract method?
- Should there be some arguments that are valid for every backend (e.g.
inline_threshold), and others that are specific to particular backends?
Questions
How to handle GRIB files? Combine before returning? Return as a hierarchy of multiple groups within a single store (like when opening with datatree)? Or return as list of VirtualZarrStores?
- Lingua principale
- Python
- Stelle
- 367
- Fork
- 97
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di fsspec/kerchunk
-
add autodask exampleAperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 68/100
-
utils.subchunk silently produces fewer sub-chunks than requested when the factor spans more than one axisForse già presa @bhaskargurram-ai l’ha presa 2 giorni fa. Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 56/100
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 68/100
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
Tutte le issue di fsspec/kerchunk
Issue simili
-
area:models enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
SACGF/variantgrid#2737 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
RedisStorage writes can persist a key without its sliding TTLForse già presa @lianbie l’ha presa oggi. Apertatriage/confirmed
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
agentscope-ai/agentscope#3878 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni
-
core
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
vectorize-io/hindsight#6458 ·
I maintainer di solito rispondono entro 1 giorno