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
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?
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 // ... # @blox: when: debug: if( PHP_DEBUG ) { // zbędny kod // } # @blox: end; // .. ?>
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.
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.
Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)