Including upstream list as submodule/subtree would be more transparent
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 35/100
- Issue-Typ
- Feature
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- git, python
- Bereich
- build-system, release
Rechercherichtung
Beginne damit zu untersuchen, wie die vorhandene public_suffix_list.dat in python-publicsuffix2-Builds eingebunden wird und wie Releases Archive erstellen. Vergleiche einen Subtree oder ein Submodul mit dem Packaging-Flow des Repositorys und verwende dabei die Datei publicsuffix/list aus dem Upstream als Quelle. Als abgeschlossen gilt die Aufgabe, wenn die Builds die Liste nicht mehr herunterladen und sowohl das wheel als auch das Tagged-Release-Archiv eine reproduzierbar gebündelte Version enthalten.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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.
- Vorherrschende Sprache
- Python
- Sterne
- 30
- Forks
- 16
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Entwicklungsumgebung
Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus aboutcode-org/python-publicsuffix2
-
codes.open is deprecated in python3.14Evtl. wieder frei Ein Pull Request dazu wurde ohne Merge geschlossen. Offen
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 52/100
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 55/100
-
Mislabeling of eTLD-`n`Offen
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 30/100
aboutcode-org/python-publicsuffix2#23 · 1 Kommentar · 1 Reaktion ·
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 35/100
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 45/100
aboutcode-org/python-publicsuffix2#21 · 1 Reaktion ·
Alle Issues in aboutcode-org/python-publicsuffix2
Ähnliche Issues
-
factory
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Arize-ai/phoenix#17420 · 1 Kommentar · 1 Reaktion ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
FireDynamics/LEDSmokeAnalysis#176 ·
Maintainer antworten meist innerhalb von 1 Tag
-
PC
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
Maintainer antworten meist innerhalb von 1 Tag
-
Make `ocifs` optionalOffendependencies
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
dlt-contrib/dlt-filesystem#51 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
Maintainer antworten meist innerhalb von 1 Tag