2017-02-03 9 views
13

Mój zespół korzysta z Pythona do rozwiązywania problemów w naszej firmie. Piszemy wiele małych niezależnych aplikacji scripty.W jaki sposób możemy budować i dystrybuować skrypty Pythona w środowisku Windows?

Musimy jednak mieć centralne okno Windows, które je uruchamia wraz ze starszymi aplikacjami.

Naszym wyzwaniem jest przechodzenie przez proces budowania i wdrażania.

Chcemy, aby Bamboo sprawdził skrypt z git, zainstalował wymagania i uruchom testy, a jeśli wszystko jest zielone, po prostu zainstaluj je w naszym pudełku produkcyjnym.

Chcielibyśmy, aby biblioteki były izolowane od skryptu do skryptu, więc nie mamy problemów z zależnościami.

Staraliśmy się, aby virtualenvs były przenośne, ale wydaje się to niemożliwe.

Pex wyglądał obiecująco, ale nie działa w oknach.

Idealnie chcesz zobaczyć folder tak:

AppOne 
    /Script.py 
    /Libs 
    /bar.egg 
    /foo.egg 
AppTwo 
    /Script2.py 
    /Libs 
    /fnord.egg 
    /fleebly.py 

Czy mamy myśleć o tym złego? Jaki jest pythonowy sposób dystrybucji skryptów w przedsiębiorstwie?

+2

Przede wszystkim proszę spojrzeć na format koła ('.whl'), to zastępuje' .egg' i może uczynić swoje życie trochę łatwiejsze – Kos

+0

W każdym razie, czy próbowałeś po prostu pakować swoje skrypty jako normalne biblioteki Pythona, przesyłając je do serwera zarządzanego przez Twoją firmę, a następnie instalując przez 'pip' gdziekolwiek jest to konieczne? – Kos

+0

Używamy kół i jaj. W rzeczywistości tak naprawdę nie powodują one problemów. Robimy pakiet i zależy od niektórych wewnętrznych bibliotek. Jednak mówisz o tym, że twój PROD box pobiera z pip, aby zainstalować zależności, zamiast mieć pole kompilacji, popchnij zbudowaną aplikację na serwer prod. W tym momencie masz swoje pudełko produkcyjne instalujące rzeczy i wyciągające z Internetu. – MattK

Odpowiedz

3

TL: DR:
Zastosowanie Docker


Krótka historia długa:

Można użyć docker stworzenie niezależnej obrazu dla każdego skryptu, który ma zostać zainstalowany.

można zainstalować python image (slim jest najlżejszym) jako środowisko bazowej dla każdego skryptu lub grupy skryptów/aplikacji i używać go jak „virtualenv”, w którym można zainstalować wszystkie zależności dla tego scenariusza.

Istnieje również integracja dla Bamboo and Docker, która może okazać się przydatna.

Oto odniesienie Docker documentation.

Możesz przetestować każdy skrypt indywidualnie w oddzielnym kontenerze, a jeśli go przejdzie, możesz użyć tego samego kontenera, aby wdrożyć go na głównym serwerze.

Nie jest to dokładnie to, o co prosisz, ale możesz użyć tego rozwiązania na każdej platformie (Windows, Linux itd.), Możesz wdrożyć wszystkie swoje skrypty na serwerze korporacyjnym (lub w dowolnym miejscu) i użyć w całej firmie.


Zastrzeżenie: to nie jest rozwiązanie, to jest rozwiązanie, że jestem świadom, które stosuje się do czasu tej odpowiedzi (2017)

+0

w dzisiejszych czasach 'docker' staje się niezbędny dla rozwoju produktów dla przedsiębiorstw –

+0

Rzeczywiście @AzatIbrakov –

+0

Hej @ Mattk Przechodziłem przez moje odpowiedzi. Czy moja odpowiedź była pomocna? Chcesz się zgodzić? –

2

Możesz być w stanie to zrobić z zgrabny jeśli stosunkowo nieznane feature, który był sneaked into Python 2.6 bez większego wysiłku: wykonywanie plików zip jako aplikacje Python.Trochę (tylko trochę) zyskało rozgłos po PEP 441 (w którym zainspirował się PEX), choć wydaje mi się, że większość ludzi wciąż nie jest tego świadoma. Chodzi o to, aby utworzyć plik zip (zalecane rozszerzenie to .pyz lub .pyzw dla aplikacji okienkowych, ale to oczywiście nie ważne) z całym kodem i modułami, które chcesz, a następnie po prostu uruchom go za pomocą Pythona. Interpreter doda zawartość pliku zip do sys.path i poszukać modułu najwyższego poziomu o nazwie __main__ i uruchomić go. Python 3.5 wprowadził nawet moduł wygody zipapp do tworzenia takich aplikacji w pakiecie, ale w rzeczywistości nie ma w nim magii i równie dobrze można go utworzyć ręcznie lub skryptowo.

W twoim przypadku, Bamboo może wykonać test, zainstalować i przetestować zależności w virtualenvs, a następnie spakować aplikację razem z bibliotekami środowiska. Nie jest to rozwiązanie jedno-klikowe, ale może załatwić sprawę bez dodatkowych narzędzi.

1

Inną możliwością jest aplikacja do usuwania paczek. Tworzy plik wykonywalny, który można wdrożyć. Python nie jest nawet wymagany do zainstalowania w wdrożonym polu produkcyjnym. Trudniej jest debugować problemy, które występują tylko w wdrożonym pudełku. Nie można również modyfikować skryptów w wdrożonym polu, które w zależności od zaufania właścicieli komputera są pozytywne lub negatywne. Patrz: http://www.pyinstaller.org/

1

Jak rozumiem, chcesz utworzyć samodzielne katalogi aplikacji na serwerze kompilacji, a następnie skopiować je do serwera produkcyjnego i uruchamiać skrypty bezpośrednio z nich. W szczególności chcesz, aby wszystkie zależności (własne i pakiety zewnętrzne) były instalowane w podkatalogu Libs w każdym katalogu aplikacji. Oto dość mocny sposób, aby to zrobić:

  1. Tworzenie katalogu najwyższego poziomu aplikacji (AppOne) i podkatalogu wewnątrz niego Libs.
  2. Użyj pip install --ignore-installed --target=Libs package_name, aby zainstalować zależności w podkatalogu .
  3. Skopiuj własne pakiety i moduły do ​​podkatalogu Libs (lub zainstaluj je tam z pip).
  4. Skopiuj plik Script.py do katalogu najwyższego poziomu.
  5. zawierać kod na górze Script.py aby dodać katalog Libs do sys.path:

    import os, sys 
    app_path = os.path.dirname(__file__) 
    lib_path = os.path.abspath(os.path.join(app_path, 'Libs')) 
    sys.path.insert(0, lib_path) 
    

To sprawi, pakiety i moduły jak Libs\bar.egg jak Libs\fleebly.py dostępnych do skryptu poprzez import bar lub import fleebly. Bez takiego kodu skrypt nie może znaleźć tych pakietów i modułów.

Jeśli chcesz usprawnić tę część skryptu, istnieje kilka opcji: (1) Umieść te linie w oddzielnym module fix_path.py w katalogu najwyższego poziomu i po prostu wywołaj import fix_path na początku skryptu. (2) Utwórz plik Libs\__init__.py z linią sys.path.insert(0, os.path.dirname(__file__)), a następnie zadzwoń pod numer import Libs ze swojego skryptu. Następnie można zaimportować Libs\x przez import x. To jest zgrabne, ale jest to niestandardowe zastosowanie mechanizmu pakietów i ścieżek (używa on Libs zarówno jako katalogu biblioteki, jak i pakietu), więc może powodować pewne zamieszanie związane z działaniem importu.

Po utworzeniu tych katalogów i plików można skopiować całą strukturę do dowolnego systemu Windows z zainstalowanym językiem Python, a następnie uruchomić ją przy użyciu cd AppOne; python Script.py lub python AppOne\Script.py. Jeśli nazwiesz swój skrypt najwyższego poziomu __main__.py zamiast Script.py, możesz uruchomić swoją aplikację, wykonując po prostu python AppOne.

Ponadto, jak @jdehesa wskazał, jeśli skrypt o nazwie __main__.py można skompresować zawartość katalogu AppOne (ale nie sam katalog AppOne) do pliku o nazwie AppOne.zip, a następnie skopiować że do serwera produkcyjnego i uruchom go, dzwoniąc pod numer python AppOne.zip. (W Pythonie 3.5 lub nowszej, można również utworzyć plik zip poprzez python -m zipapp AppOne jeśli skrypt jest wywoływany __main__.py. Można również mieć możliwość korzystania z python -m zipapp AppOne -m Script jeśli skrypt jest wywoływany Script.py. Zobacz https://docs.python.org/3/library/zipapp.html.)

+0

właściwie względna ścieżka do "głównego skryptu" działa dobrze, mamy tylko jedną linijkę (plus import): 'sys.path.append ('Libs')'. Plik '__init__' dodający biblioteki - na początku brzmi seksownie, ale ja wolę bootstrap.py, który znajduje się w katalogu aplikacji zawierającym ten kod. – dualed

+0

@dualed, Względne ścieżki są obliczane w odniesieniu do bieżącego katalogu roboczego procesu, który zwykle jest katalogiem, z którego został uruchomiony skrypt. Więc jeśli ktoś uruchomi skrypt z zewnątrz 'AppOne' (np. Pójdą na wyższy poziom i wywołają' python AppOne \ __ master __. Py' lub 'python AppOne'), wtedy' sys.path.append ('Libs') nie wskazuje na katalog 'AppOne \ Libs', a skrypt się zepsuje. Kod, który zasugerowałem jest o wiele bardziej stabilny, ponieważ oblicza ścieżkę względem położenia skryptu, a nie bieżącego katalogu roboczego. –

0

Tego rodzaju rzeczy można łatwo rozpatrywane python setup.py

setup.py Próbka

from setuptools import setup 

setup(
    name=name_for_distribution, 
    version=version_number, 
    py_modules=[pythonfiles], 
    install_requires=[ 
     python packages that need to be installed 
    ] 
) 

Tworzenie wirtualnego środowiska, włączyć go i uruchomić: python setup.py zainstalować

Uważam, że jest to najbardziej pytonowy sposób dystrybucji i pakowania projektu.

linki Reading:

https://pythonhosted.org/an_example_pypi_project/setuptools.html https://docs.python.org/2/distutils/setupscript.html