Signaler un spam en CLI

Ce matin j’ai reçu un spam (qui ne commençait pas par « Dear Python, » cette fois, ça c’était hier, faut suivre !

J’ai donc voulu le remonter à signal-spam.fr mais en ce moment j’utilise Protonmail…

Depuis Protonmail c’est simple de télécharger un email, donc je me retrouve avec un .eml et à coup de xclip c’est vite copié dans le formulaire de signal-spam.fr, mais bon, on peut faire mieux.

J’ai donc vite fait écrit :

Voilà, ça m’évite un copier-coller.

Je sais que tu as le flag « une parenthèse n’est pas fermée » levé dans ton cerveau depuis la première ligne, c’est pas agréable ? Aller je suis gentil, voilà ) tu peux baisser ton flag et passer une bonne journée.

2 « J'aime »

Rien à dire, c’est propre. Et c’est intéressant d’avoir un tout petit projet pour pouvoir “copier” le pyproject.toml aussi :wink:

J’ai donc rajouté une section releasing dans le README pour expliquer comment publier une nouvelle version (TL;DR : python -m build && python -m twine upload dist/*).

2 « J'aime »

Novice en packaging / releasing (mais je vais bientôt essayer), je comprend que n’importe qui peut publier une nouvelle version de signal-spam sur pypi.org, ou bien je me trompe?

Non, maintenant que « j’ai le nom » il n’y a que moi qui ai le droit d’uploader une version de signal-spam (et ceux que j’ajoute dans l’interface d’administration du projet sur pypi.org).

Par contre « premier upload, premier servi » si tu veux uploader signal-spam-2 tu peux, et dès que tu auras envoyé ta première version, seul toi pourra en envoyer de nouvelles.

Donc oui twine a besoin de ton identité PyPI, soit login/mot de passe, soit mieux, jeton d’upload.

Ok donc la section ne concerne que les personnes associées au projet du côté de PyPI alors?

Oui. J’ai rajouté ça surtout pour ceux qui veulent copier-coller le pyproject.toml, pour qu’ils sachent quoi faire avec. (Bon on pourrait faire un cookiecutter aussi…).