Gestionar subida de archivos a internet

[javiersanp]

La aplicación se encarga de la descarga de los archivos de Catastro y su transformación. El usuario tiene que encargarse de subir el resultado al repositorio catastro-import. El programa podría encargarse de ello ocultando la complejidad de usar git para un no iniciado.

[Crashillo]

Y ahorrarse el pedir permisos de escritura para el repositorio :smile:

[javiersanp]

Es posible. Quizá incluso cuenta en GitHub. La idea que voy a probar es crear un repositorio local vacío, meter la carpeta del municipio dentro y hacer una PR al repo común, ¿funcionará?

[Crashillo]

Más que un repo nuevo, se me ocurre utilizar las Github Actions en https://github.com/OSM-es/catastro-import/, para que se cree automáticamente una PR. Puesto que será automático, los ficheros que se commitearán (su nombre, su estructura de carpetas, etc..) no serán necesarios de revisar y se puede utilizar otra Action (x. ej. https://github.com/marketplace/actions/auto-merge-pull-request) para mergearlos en master.

[Crashillo]

Ahora bien, quizás haya que envolver todos estos pasos con algún flag del programa --upload (o negado --no-upload), para que el usuario escoja si desea o no hacer una PR (puede estar probando)

[javiersanp]

Lo de la PR no lo tengo claro. Se trata de un repositorio bastante grande, 1GB. Ya estamos abusando un poco de github al usarlo para algo que no es estrictamente desarrollo software. Si cada usuario se hace su propio fork multiplicamos por 20x por lo menos el consumo de recursos.

[javiersanp]

Subir un municipio por primera vez:

git init repo-05015
cp 05015/tasks/93579.osm.gz repo-05015/
cd repo-05015/
git remote add origin https://github.com/javiersanp/prueba.git
git checkout -b 05015
git add 93579.osm.gz
git commit -m "Añade 05015"
git push origin 05015

[javiersanp]

https://gitpython.readthedocs.io/

[javiersanp]

Dentro del docker, el usuario es 'catastro' con home en '/catastro'. La identificación de git se guarda en /catastro/.gitconfig

[user]
    email = ****
    name = ****

La carpeta /catastro está conectada con la carpeta actual ($pwd) del host. Por lo que si el usuario crea el archivo .gitconfig ahí, está configurando git dentro del docker.

[javiersanp]

Si el contenido es este, la primera vez que se usa git pide usuario y contraseña, el resto quedan almacenadas.

[user]
    email = ****
    name = ****
[credential]
    helper = cache

[javiersanp]

Idea: reusar la carpeta task como repositorio en lugar de tener los archivos separados. Como hace poco separamos distintas carpetas para cada subdivisión de un municipio, volverlas a unir pero manteniendo dentro por separado los archivos como copia de seguridad. O sea, en lugar de

tasks-arganzuela
tasks-chamartin
....

tasks/*.gz
tasks/arganzuela (highway_ names.csv, report.txt, ...)
tasks/chamartin (idem)

[javiersanp]

https://www.devdungeon.com/content/working-git-repositories-python https://azzamsa.com/n/gitpython-intro/

import os
from git import GitConfigParser, Repo, exc

url = 'https://github.com/javiersanp/prueba.git'
mun_code = '38012'
tasks_folder = 'tasks'
repo_path = f'{mun_code}/{tasks_folder}'
config_path = os.path.normpath(os.path.expanduser("~/.gitconfig"))
parser = GitConfigParser(config_path)

if not parser.has_section('user'):
    print("Si no tienes cuenta, regístrate en github.com.")
    user_email = input("Introduce tu correo electrónico: ")
    user_name = input("Tu nombre: ")
    parser.set_value('user', 'name', user_name).release()
    parser.set_value('user', 'email', user_email).release()
if not parser.has_section('credential'):
    parser.set_value('credential', 'helper', 'cache').release()

try:
    # Conecta repositorio en tasks
    repo = Repo(repo_path)
    origin = repo.remotes.origin
    oper = 'Actualiza'
except exc.InvalidGitRepositoryError:
    # Si es la primera vez lo inicializa
    # git init tasks
    repo = Repo.init(repo_path)
    oper = 'Crea'
    # git remote add origin $url
    try:
        origin = repo.create_remote('origin', url=url)
    except exc.GitCommandError as error:
        print(f'Error creating remote: {error}')

# Si la rama ya existe
if mun_code in repo.branches:
    # git checkout 38004
    repo.branches[mun_code].checkout()
else:  # si no la crea
    # git checkout -b 38004
    repo.git.checkout('-b', mun_code)

# git add -A
repo.git.add('-A')
# git commit -m "Añade 38004"
repo.index.commit(f'{oper} {mun_code}')

# git push origin 38004
origin.push(mun_code).raise_if_error()

[javiersanp]

credential helper cache es temporal

La instalación de libsecret en el docker desde apt-get (libsecret-1-0 libsecret-1-dev) no funciona: la carpeta /usr/share/doc/git/contrib/credential/libsecret/ está vacía.

Los descargo e instalo a mano

WORKDIR /usr/share/doc/git/contrib/credential/libsecret/
RUN curl https://raw.githubusercontent.com/git/git/master/contrib/credential/libsecret/Makefile -o Makefile \
    && curl https://raw.githubusercontent.com/git/git/master/contrib/credential/libsecret/git-credential-libsecret.c -o git-credential-libsecret.c \
    && make

No tira

git config --global credential.helper /usr/share/doc/git/contrib/credential/libsecret/git-credential-libsecret
git push
** (process:22): CRITICAL **: 22:57:11.931: could not connect to Secret Service: Cannot autolaunch D-Bus without X11 $DISPLAY
dbus-launch git push origin master
** (process:35): CRITICAL **: 22:57:39.999: could not connect to Secret Service: Error calling StartServiceByName for org.freedesktop.secrets: Failed to execute program org.freedesktop.secrets: Operation not permitted

Atajo: renunciar a almacenar la contraseña. Tampoco se usa con tanta frecuencia.

Este cambio en el dockerfile evita que git pregunte por la configuración la primera vez que se usa

RUN git config --system user.email "catatom2osm@gmail.com" \
    && git config --system user.name "CatAtom2Osm"

[Crashillo]

Comparto la opinión de usar github como ftp no es buena idea. Puesto que lo único que necesita el programa es el almacenamiento de archivos, no buscaría la complicación añadiendo librerías que gestionen git.

Creo que sería mejor enfoque sería subirlas a un ftp mediante ftplib. Ahora bien, hay dos problemillas:

• Se perdería control de versiones. En caso de actualización de una zona (imagina que al par de años) los nuevos archivos pisarían a los viejos, no sé si es el comportamiento deseado, de todos modos es un impacto bajo, y además existe esto, git-ftp
• Actualmente no tenemos un ftp. Si el tema de los servicios web sale adelante, quizá tenga sentido tener un pequeño Dockerfile ya preparado con un servidor ftp