version

6.6.2018 11:36 | Přečteno: 2180× | | poslední úprava: 6.6.2018 20:48

Již nějaký ten pátek ve svých projektech používám pomocný script version.py který byl modifikován speciálně pro daný projekt a zajišťoval tyto věci:

1. Hromadnou úpravu version stringu ve specifikovaných souborech
2. Commit version souborů do GITu
3. Vytvoření GIT TAGu s danou verzí
4. Push změn a TAGu na server

V posledním projektu se ale s tímto scriptem vyskytly nějaké ty problémy a bylo třeba jej trochu poupravit, a v tu chvíli nastala ta nemilá situace kdy v x projektech byl zastaralý na míru pro projekt upravený version.py...

No co teď s tím že ? Řešení je jasné:

Přetavení version.py do univerzálního toolu na hromadnou změnu version stringu v projektu který může použít každý komu se hodí.

A tak vznikl version (Ehm, GitHub)(GitLab)

Co že tedy version umí ?

1. Modifikuje všechny soubory v projektu obsahující version string jedním jednoduchým příkazem
2. Přidává modifikované version soubory do GIT commitu a pushuje je na server
3. Umí vytvořit version GIT TAG
4. Kontroluje zda li mají všechny version soubory v projektu zapsanou stejnou verzi
5. Kontroluje zda li nejsou žádné modifikované soubory spravované VCS GIT v projektu před změnou verze
6. Kontroluje zda li je nová verze vyšší než stará verze
7. Kontroluje validitu nově zadaného version string
8. Dokáže dělat kroky v patch/minor/major version jednoduše příkazem "+" etc.

Jak se to používá ?

Použití je jednoduché prostě v rootu vašeho projektu spustíte jeden z těchto příkazů:

Zjištění aktuální verze

$ version
NEBO
$ version status

Nastavení nové verze

$ version 1.0.1
NEBO
$ version mark 1.0.1

Posun o specifikovaný počet kroků v major/minor/patch číslu verze

Pro posun se používá příkaz "+" ve formátu (+{1-3})({\d+}) kde první skupina detekuje počet "+" a dle toho určuje zda li se jedná o patch(+)/minor(++)/major(+++) změnu, druhá skupina určuje číslo posunu dané verze (default: 1)

Příklad

• + Znamená posun o jedna v patch version
• ++ Znamená posun o jedna v minor version
• +++ Znamená posun o jedna v major version
• +2 Znamená posun o dva v patch version
• ++2 Znamená posun o dva v minor version
• +++2 Znamená posun o dva v major version
• A tak podobně...

Takže příkazy pak vypadají takto

$ version + #pro posun o 1 v patch verzi
OR
$ version +10 #pro posun o 10 v patch verzi
OR
$ version ++1 #pro posun o 1 v minor verzi

Pro více možností viz:

version --help

Main entry-point into the 'version' application.

This is a version

License: GPL-3.0
Website: https://github.com/Salamek/version

Command details:
    mark                Mark project specified by --project_dir by <version>.
    status              Show current --project_dir version.


Usage:
    version mark <version> [-p DIR] [-c FILE] [--dry] [--all_yes]
    version status [-p DIR] [-c FILE]
    version 
    version <version> [-p DIR] [-c FILE] [--dry] [--all_yes]
    version (-h | --help)
    version (-v | --version)

Options:
    --dry                       Run as usually but don't change anything.
    -p DIR --project_dir=DIR    Project directory, if not set current is used.
    -y --all_yes                Answer YES to all prompts.
    -d --project_dir=DIR        Project directory, if not set current is used.
    -c FILE --config_file=FILE  Path to config file, if not set --project_dir/version.conf is used
    --version                   Show version.

Instalace

Debian a deriváty

Přidejte repozitář těmito příkazy

$ wget -O - https://apt.salamek.cz/apt/conf/salamek.gpg.key|sudo apt-key add -
$ echo "deb     https://apt.salamek.cz/apt all main" | sudo tee /etc/apt/sources.list.d/salamek.cz.list

Pak můžete nainstalovat python3-version pomocí

$ apt update && apt install python3-version

Archlinux

Přidejte repozitář na konec souboru /etc/pacman.conf

[salamek]
Server = https://arch.salamek.cz/any
SigLevel = Optional

a pak nainstalujte příkazem

$ pacman -Sy version

Konfigurace

Tohle všechno se samozřejmě neobejde bez nějaké té konfigurace která je uložena v $PROJECT_ROOT/.version.yml (Pouze REGEXPS a VERSION_FILES jsou povinné):

# GIT Configuration
GIT:
    AUTO_COMMIT: true # Autocommitnout modifikované version soubory (default: true)
    AUTO_TAG: true # Vytvořit GIT TAG s novou verzí (default: true)
    AUTO_PUSH: true # Automaticky pushnout na server false=disabled, true=enabled, 'remote_name'=enabled and push to remote_name (default: true)
    COMMIT_MESSAGE: 'New version {version}' # Text použít v commit message {version} je kotva pro version string (default: 'New version {version}')

# Pole regexpů použitých pro nalezení version stringů v VERSION_FILES
# Klíč je název regexpu a hodnota je samotný regexp
# Přidejte své vlastní a smažte neužitečné
REGEXPS:
    'python': __version__\s*=\s*\'(?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)\' # Regexp for version format commonly used in python
    'setup.py': version\s*=\s*\'(?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)\' # Regexp for version format commonly used in python setup.py
    'PKGBUILD': pkgver\s*=\s*(?P<version>.*) # Regexp used in PKGBUILD

# Pole version souborů které mají být nalezeny a upraven, glob formát cest je podporován
# Klíč je glob cesta a hodnota je jméno regexpu který se má použít k nalezení version string v nalezených souborech
# Přidejte své vlastní a smažte neužitečné
VERSION_FILES:
    'version/__init__.py': 'python'
    'setup.py': 'setup.py'
    'archlinux/PKGBUILD': 'PKGBUILD'

Tak snad se to někomu z vás bude hodit        

Komentáře

[Josef Kufner]

Obvykle verzi v programech řeším tak, že při buildu si někam uložím výstup z git describe. Prostě vygeneruju jeden malý soubor, který obsahuje definici konstanty, nebo je součástí konfigurace projektu.

U mnoha projektů je vidět ručně udržovaný ChangeLog a commity, které takovou konstantu někde upravují ručně, ale nikdy to není o moc víc jak jednořádková změna. Proč to tedy tak komplikovat?

[Salamek]

Když mam vice jazyku / build scriptu / configuraku v projektu, tak to proste jednoduše nejde, zkoušel jsem používat single point version storage, ale vzdy to dopadlo nějakou prasofunkcionalitou v urcitch skriptech...

[Salamek]

Vlastne odpoved je primo v prilozenem konfiguraku, kde se meni verze v PKGBUILD pro archlinux, verze v setup.py (kde byla dříve naprasená funkce co lovila verzi z version/__init__.py) a pak finalne uprava v version/__init__.py kde se drive nachazela taky pochybnost...
A hlavne nezapomen na to ze nektere projekty maji verzi napriklad v hlavickach kazdeho souboru, dokumentaci a tak podobne...
Takhle jsem mohl vsechny version prasarny vyjmout z projektu a nechat tam ciste stringy... navic to za me resi git add+commit+push+pushtag a hlavne mi to nedovoli vydat verzi kdyz mam v repu neulozene zmeny.

[Michal Kubeček]

Tohle se dá často automatizovat pomocí atributu export-subst (viz gitattributes(5)).

[Bystroushaak]

Osobně používám v python projektech parsování changelogu:

#! /usr/bin/env python3
from setuptools import setup
from setuptools import find_packages


changelog = open('CHANGELOG.rst').read()
long_description = open('README.rst').read() + "\n\n" + changelog


def get_version(data):
    def all_same(s):
        return all(x == s[0] for x in s)

    def has_digit(s):
        return any(x.isdigit() for x in s)

    data = data.splitlines()
    return list(
        line for line, underline in zip(data, data[1:])
        if (len(line) == len(underline) and
            all_same(underline) and
            has_digit(line) and
            "." in line),
    )[0]


setup(
    name='...',
    version=get_version(changelog),
    description="...",
    long_description=long_description,
    url='...',

    author='...',
    author_email='...',
    license='MIT',

    packages=find_packages('src'),
    package_dir={'': 'src'},

    zip_safe=False,
    include_package_data=True,
    install_requires=open("requirements.txt").read().splitlines()
)

[Salamek]

No tohle ale pravě resi jen setup.py a CHANGELOG.rst co pak ale s PKGBUILD, hlavickami etc. BTW pouzival jsem neco podobneho, ale nakonec me to nasralo Jinak opreni o changelog neni spatny napad, mozna tam pridam spravu/automaticke generovani changelogu a odpadne srani i s changelogem

[Bystroushaak]

Já jsem jeden čas skládal changelog z git logu, ale pak mi došlo, že je to v podstatě nesmysl a že uživatele zajímají spíš ty podstatnější věci (změny api, nová fukncionalita atd), než každá blbost co jsem commitoval.

[Salamek]

No me napadlo ze by se commity braly jen takove co by vyhovovaly danemu regexpu ktery si nastavi v .version.yml.
Napr. Commit musi zacinat velkym pismenem, koncit teckou, obsahovat alespon 4 slova a za teckout koncit (Closes|Fixes)\s+#\d+. Protoze dulezite commity by mely mit sve Issue... to alespon cloveka donuti nepsat sracky do commit messages... jinak si bude muset CHANGELOG doplnovat rucne

[Josef Kufner]

Spíš by dávalo smysl dát do komentáře commitu nějakou značku s textem a ty pak sesbírat do ChangeLogu. Ale takový komentář se klidně dá připsat do ChangeLogu rovnou a je to bez komplikací.

[Salamek]

A nebo se taky da rovnou na changelog vykaslat No ta tvoje znacka je vyresena v tom mem predchozim navrhu, proste misto spravne formatovaneho commitu budes v regexpu hledat onu znacku... No zkusim neco vymyslet a otestovat jak mi s tim pujde workflow.

[marbu]

co pak ale s PKGBUILD

Vygenerovat, případně přegenerovat, ten PKGBUILD na základě setuptools metadat z setup.py? Navíc nevím jakou výhodu má mít PKGBUILD soubor přímo v repu s kódem, když aby to k něčemu bylo, stejně ten PKGBUILD musím udržovat v AURu.

[Salamek]

Vygenerovat, případně přegenerovat, ten PKGBUILD na základě setuptools metadat z setup.py

A na to existuje nejaky tool ?

Navíc nevím jakou výhodu má mít PKGBUILD soubor přímo v repu s kódem, když aby to k něčemu bylo, stejně ten PKGBUILD musím udržovat v AURu.

Protoze mam CI (na vlastnim HW) ktere mi buildi balicky pri release do meho arch repa a je to tak pro me pohodlnejsi nez to lovit nekde na AUR ?

Jasne mohl bych v CI udelat release, stahnout archiv, spocitat sha256sum, vygenerovat ten PKGBUILD a nahrat jej na AUR, a pak ten balicek sestavit a uploadnout do repa. Ale to je ted pro me zbytecna prace. Ted jsem se jeste dival na AUR a zda se, ze se tam da vlozit jen jeden public key (netestoval jsem) a to situaci celkem komplikuje kdyz CI nemuze mit separe keypair.

[Salamek]

Ah tak kecam: Tip: You can add multiple public keys to your profile by separating them with a newline in the input field. Takze v tom neni problem

[Salamek]

Ale samozrejme mas pravdu ze by se hodilo mit PKGBUILD na AUR, ale neni to pro me ted priorita protoze ja uz mam sestaveny balicek v repo A dokud nekdo nevytvori issue ze mu vadi ze neni v AUR...

[Salamek]

No a hlavne je pro me super jednoduchost kdy proste dam

$ version +

a mam hotovo

[horada]

Gitlab link => 404 The page could not be found or you don't have permission to view it.

[Bystroushaak]

On gitlab se docela hroutí pod náporem. Dával jsem před chvíli importovat nějaké moje repa z Githubu, jen abych si to zkusil a několikrát to hodilo 500.

[Salamek]

Sorac, ten projekt se naimportoval jako private, a ja si toho nevsiml... ted uz by to melo byt ok

[ewew]

Pekne. ale nie je to komplikované ? Nepoznám tento jazyk ale nešlo by to urobiť tak, že jednotlive súbory budú mať link na súbor s verziou ? 

[Salamek]

Ten version file neni jen soubor obsahujici string 1.2.3 ale soubor s libovolnym obsahem, tzn kod, dokumentace, hlaviky souboru etc. proto se to parsuje pomoci regexp.. napr:

__version__ = '1.2.3'

nebo

foo=bar
pkgver=1.2.3
bar=foo

nebo

/**
 * Text
 * This is app version 1.2.3
 * Text...
 */

No a vsude tady treba potrebujes zmenit version na 1.2.4...

[FrostyX]

Hezký tool. Alternativně se dá použít tito nebo rpkg.