Update versement transport rates

[laem]

• Évolution du système socio-fiscal, Amélioration technique
• Périodes concernées : de 2016 à 2017
• Zones impactées : openfisca_france/assets/versement_transport/.
• Détails :
  • Mise à jour des taux de versement transport suite aux changements annuels du mois d'avril
  • Nettoyage des anciens fichiers, pour réduire la taille du dépôt à partir de ce commit

---

Ces changements :

• Corrigent ou améliorent un calcul déjà existant.
• Modifient des éléments non fonctionnels de ce dépôt (nettoyage des fichiers d'assets).

[laem]

@fpagnoux After this merge you might want to add the option --depth to the 'install for developpers' section of the doc if ~8 mega less to download makes a difference

[fpagnoux]

Thanks for the advice !

The competition to become the best code remover is getting fierce 😆

[laem]

I will merge this tomorrow, unless something's wrong @benjello

[benjello]

@laem : pourrais-tu préciser quels sont les fichiers qui ont été virés stp ? Et lequel reste.
L'idée est de récupérer au moins le fichier d'origine.
Si tu as un autre source pour ces taux je suis également preneur.
Je rapatrierai tout cela ailleurs.
Merci d'avance.

[laem]

Le seul qui reste, taux.json, est un fichier des taux historisés, à jour au 1er avril 2017, par commune, AOT et SMT, récupéré sur URRSAF.fr.
J'avais dans le passé ajouté l'équivalent en .yaml, pour la lisibilité. Mais il s'avère que YAML est bien trop lent à parcourir (en python au moins), donc je l'enlève.
Les .csv sont les fichiers historiques d'OpenFisca je crois, qui ne contiennent pas l'historique et sont périmés. Le fichier extract_taux était utilisé pour les fichiers csv.

[laem]

Exemple (github ne gère pas ces diffs...) :

Par exemple, Brest dans le nouveau .json :

'29019':
  codePostal: '29200'
  nomLaposte: BREST
  nomAcoss: BREST
  aot:
    nom: COMMUNAUTE URBAINE DE BREST
    taux:
      '2006-01-01': '1.65'
      '1993-03-01': '1.05'
      '1992-06-01': '1.1'
      '1975-07-01': '1'
      '2009-09-01': '1.8'

Dans l'ancien .csv :

29200;29019;BREST ;BREST;COMMUNAUTE URBAINE DE BREST;1,8;;

[laem]

@benjello @fpagnoux @cbenz pouvez-vous merger cette PR svp ? Ou m'ajouter à nouveau aux contributeurs -france ?

[benjello]

@fpagnoux : tout est ok pour moi
@laem : je laisse @fpagnoux merger ou te donner les droits

[laem]

@fpagnoux

Pour pouvoir faire tourner les tests d'une PR, il faut que setup.py et CHANGELOG.md soient à jour, donc que l'on y ait défini et inscrit une nouvelle version.

Sauf que si quelqu'un pousse entre temps, c'est obsolète, il faut rebaser et résoudre les conflits, 3 fois pour cette PR (ou alors je m'y prends mal ?). Ce problème devrait s'empirer avec le nombre de contributeurs.

J'imagine que ce n'est pas simple, mais ce serait super de pouvoir définir le type de mise à jour (major, minor, patch) et la description du CHANGELOG dans le texte de la PR, puis que le CI se charge d'incrémenter la version et d'inscrire ces infos.

[fpagnoux]

@laem

En général, j'adopte le workflow suivant :

• J'ouvre ma PR
• Je demande une review.
  • À partir de ce moment je m'interdis de rebaser, vu que les force-push sont pénibles pour les reviewers.
• Je fais évoluer mon code en fonction des remarques
  • Si par hasard les tests de la PR ne passent plus parce que quelqu'un a publié un package avec la même version que moi, je me base sur les tests 'push' de github, qui sont strictement équivalents d'un point de vue de la non-régression.
• Une fois ma PR est approuvée, je rebase et je résous les conflicts potentiels sur les setup.py et le CHANGELOG.md. Ces conflits sont très fréquents, mais leur résolution est triviale.
• Dès que les tests sont passés, je merge.

En général, je ne résous les conflits qu'une seule fois.

J'imagine que ce n'est pas simple, mais ce serait super de pouvoir définir le type de mise à jour (major, minor, patch) et la description du CHANGELOG dans le texte de la PR, puis que le CI se charge d'incrémenter la version et d'inscrire ces infos.

Fonctionnellement ce serait super, mais je n'ai aucune idée de comment faire. Il faudrait que travis est connaissance du texte de la PR, ce qui est peut-être possible (il connaît le numéro de la PR par exemple). Si tu as le temps et que tu veux creuser ça, tu es le bienvenue :).

[MattiSG]

Pointeurs :

• https://github.com/semantic-release/semantic-release
• https://github.com/skywinder/github-changelog-generator

😉