Including upstream list as submodule/subtree would be more transparent
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- git, python
- Ambito
- build-system, release
Direzione di ricerca
Inizia esaminando come il file public_suffix_list.dat esistente viene incluso nelle build di python-publicsuffix2 e come le release creano gli archivi. Confronta un subtree o un submodule con il flusso di packaging del repository, utilizzando come sorgente il file publicsuffix/list dell'upstream. Il lavoro è completato quando le build non scaricano più la lista e sia il wheel sia l'archivio del tagged release contengono una versione integrata riproducibile.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
During packaging of python-publicsuffix2 I realized, that downloading the publicsuffix list during build time makes it unreproducible (any time the package is rebuilt, it will have a different list).
My suggestion would be to include the publicsuffix list from upstream directly as e.g. a git submodule or git subtree (the latter is preferred as this way the files actually end up in an automatically generated tarball on github when tagging a release) and not download it during build time at all to ensure reproducibility raise transparency.
The data lives in this repository already, so it could also be copied manually, but IMHO a subtree or submodule is the more transparent way of dealing with this.
Currently only the wheel on pypi.org is really ensured to carry the currently bundled version of the publicsuffix list. For anyone else building this package, this assumption is not valid.
- Lingua principale
- Python
- Stelle
- 30
- Fork
- 16
- 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 aboutcode-org/python-publicsuffix2
-
codes.open is deprecated in python3.14Forse di nuovo libera Una pull request per questa issue è stata chiusa senza essere unita. Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 52/100
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 55/100
-
Mislabeling of eTLD-`n`Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 30/100
aboutcode-org/python-publicsuffix2#23 · 1 commento · 1 reazione ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 35/100
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 45/100
aboutcode-org/python-publicsuffix2#21 · 1 reazione ·
Tutte le issue di aboutcode-org/python-publicsuffix2
Issue simili
-
infrastructure
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
NatLabRockies/H2Integrate#977 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
topoteretes/cognee#6470 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
-
area:docs priority:p2 type:docs wave:9
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 84/100
jejjohnson/radtrax#293 ·
I maintainer di solito rispondono entro 1 giorno
-
bug core plugins
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
bunkerity/bunkerweb#4121 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno