Uniwersalny preprocesor kodu źródłowego Opcje

[K0FF]

Programując w PHP oraz w kilku innych językach skryptowych brakowało mi czegoś w rodzaju preprocesora kodu źródłowego: czegoś co np. usunie zbędne fragmenty kodu w wersji produkcyjnej skryptu lub połączy kilka plików w jeden [..,itd]. Używaliśmy w tych celach różnych narzędzi i skryptów, które w pewien sposób "dawały radę", ale postanowiłem stworzyć coś bardziej uniwersalnego [..] i napisałem jakiś czas temu w Pythonie ("oswajam węża") coś w rodzaju uniwersalnego preprecesora kodu źródłowego, który można uruchomić by wykonał polecenia z komentarzy i np. wygenerował nowy plik wyjściowy z wersją na produkcje.

Pogram raczej spodobał się moim znajomym, którzy go testowali przez ostatnie dwa tygodnie, a teraz jest w tzw. fazie publicznej alfy i jak na razie wszystko działa dobrze. Ponieważ podejrzewam, że mój program może tutaj kogoś zainteresować, to prywatnie będę mile wdzięczny za rzucenie okiem i feedback, oraz w miarę możliwości i zainteresowania zapraszam do zabawy.

https://github.com/k0ff/blox

Ten post edytował K0FF 30.12.2017, 23:57:34

[Pyton_000]

Jako że ja też troszkę z Pythonem miałem przyjemność to pozwoliłem sobie zerknąć w kod

Do tworzenia CLI ja używałem Docopt: https://github.com/docopt/docopt
Jest fajny wygodny i uprasszcza cały proces tworzenia parametrów.

- Nie stosuj @ w argumentach. źle to wygląda i kiepsko używa.
- Jako argumenty metod użuwaj małych liter, duże stosuje się do CONS


Z tego co rozumiem to robię sobie pliczek .bx który zawiera definicje np. że mogę sobie coś gdzieś dopisać, coś usunąć z kodu. Nadawałoby się to w sumie jako tool podpięty pod Git Hook do robienia czegoś.
Ogólnie fajny pomysm.

PS. Pod jaką wersję Pythona pisaleś? 2.7?

[K0FF]

Program pisałem z myślą o Python.3.x, ale tak by działał też na Pythonie 2.7 testując go pobieżnie na obu wersjach.
W wolnej chwili z chęcią przetestuje ten Docopt gdy będę miał wolną chwilę, ale nieprędko bo ogólnie mam tzw. "noworoczną" reorganizacje pracy
Ogólnie najfajniej by było zrobić, by można instalować ten program przez pip, ale jeszcze nie wiem co i jak z tym..

Co do tych argumentów z tą @ to chciałem oddzielić argumenty wpływające na interpreter i z mojego założenia to powinno się ich używać w szczególnych przypadkach, np. podczas debugowania skryptów itp. a pozostałe argumenty są traktowane jak zmienne interpretera np. wykonując `blox --@debug` debugujemy nasz skrypt, a `blox --debug` ustawiamy zmienną debug na true i możemy jej używać w interpreterze np. w skrypcie

```

[PHP] pobierz, plaintext 
<?php
// ...
# @blox: when: debug:
if( PHP_DEBUG )
{
   // zbędny kod //
}
# @blox: end;
// ..
?>
[PHP] pobierz, plaintext 

```

gdy np. wykonamy `blox plik.php wyjscie.php --not-debug` to na pliku wyjściowym nie będziemy mieli tak oznaczonego kodu, który służył nam np. tylko do debugowania czegoś tam jedynie na deweloperce. Co do tych argumentów pisanych dużą literą może rzeczywiście[..], ale czytałem jakiegoś PEP'a i tam były jakieś przykłady, które mogłem źle zrozumieć, że niektóre ważniejsze obiekty były nazywane dużymi literami i pomyślałem [..], zresztą nieważne - ograniczę to w przyszłości, by nie było z tego powodów jakiś niejasności w nazewnictwie zmiennych.

Ogólnie to pliki bx są dodane do repozytorium jako przykłady zamiast dokumentacji (na której eleganckie opracowanie nie znalazłem wolnego czasu), by po rzuceniu okiem na taki plik mniej-więcej wiedzieć jak wygląda składnia preprocesora, ale ponieważ polecenia są interpretowane tylko z linijek rozpoczynających się jako komentarze to z założenia można je wstawiać w dowolnym kodzie źródłowym, do czego właśnie powstało to narzędzie i sam mam zamiar używać go z git hook'ami, bo przyda mi się do pewnych zastosowań.

Dzięki za zainteresowanie
SZCZĘŚLIWEGO NOWEGO ROKU!
Pozdrawiam

[Pyton_000]

Jeśli chodzi o zmienne do skryptu to chyba lepiej będzie używać po prostu environments, a to cli przekazywać tylko opcje które wpływają na progam.

Ew. jak już chcesz przekazywać w cli to możesz np. `-e var=val -e var2=val2` itd.

Co do PIP: https://marthall.github.io/blog/how-to-package-a-python-app/

szybko łatwo i przyjemnie

Przeglądając pliki bx w miarę przyswoiłem co i jak działa więc jest to w miarę przystępna forma dokumentacji.

[K0FF]

Jeszcze w tym miesiącu zrobię z tego pakiet, a co zmiennych: blox jeśli nie zdefiniowaliśmy nim zmiennej to bierze zmienne systemowe, tzn. używając {@:nazwa.zmiennej} bierze pierw zmienną lokalną, a jeśli takiej niema to użyje zmiennej systemowej, jest w repozytorium taki przykład co używa {@:zmienna}, {#:zmienna}, {$:zmienna}, gzie dodatkowo # to tylko zmienne lokalne interpretera, a $ to tylko zmienne systemowe.

Dodałem zmienne jako parametr w cli, bo wpływają one na wyjście (np. bloki warunkowe) w procesie generowania wyjścia. Można używać --zmiennej, --not-zmienna --zmienna:wartość by np. za pomocą jednego hook'a wygenerować kilka wersji pliku itp.

Będę jeszcze działał w temacie tego procesora za kilka miesięcy (na wiosnę) jak go trochę sam poużywam w jakiś swoich projektach i zbiorę feedback od znajomych i zainteresowanych (mam lokalnie plik blox.todo). Teraz jak będę miał wolny czas na pythona to będę uczył się jak pracować z źródłami danych - jak baza danych sqlite, pliki xml i json itp. by móc już coś konkretnego zaprogramować w tym języku, bo mam od dłuższego czasu pomysł na dwa inne i niezobowiązujące programy, które będę sobie pisał w pythonie po godzinach w zależności od ochoty, które z założenia - w dłuższej perspektywie ułatwią mi codzienną prace i pozwolą opanować w praktyce kolejny język programowania, ale to jest już temat na inny wątek.

Ten post edytował K0FF 3.01.2018, 13:24:25