Pewnego razu wybrałem się na MeetUp którego głównym tematem było robienie wizualizacji w R przy pomocy biblioteki ggplot2. Na spotkaniu nie było aż tak dużo osób, jak się spodziewałem (ciekawe dlaczego, przecież ktoś rozdaje darmową wiedzę), więc w kameralnym gronie przystąpiliśmy do przygotowywania sobie środowiska pracy. Po co nam było środowisko pracy? Otóż spotkanie to w planie miało również część warsztatową i osoba prowadząca przygotowała nawet zadanie dla uczestników. Kilka osób chyba nie doczytało szczegółów i zjawiło się bez działającego środowiska pracy. Ja byłem jedną z tych osób :D. Zapytałem się więc, czy mamy na sali Wi-Fi (tak!) i jakie jest do niego hasło. Następnie w trzech poleceniach w terminalu zainstalowałem wszystko, co było mi potrzebne. Oczywiście musiałem chwilkę poczekać, aż pobiorą się wszystkie potrzebne elementy środowiska. W międzyczasie widziałem jednak, jak kilka osób dość intensywnie walczy z tym problemem. Pomyślałem więc, że może warto podzielić się tą sztuczką. Sądzę, że przyda się ona nie tylko na MeetUpowych warsztatach.
Anaconda
Część systemów operacyjnych – jak na przykład dystrybucje Linux bazujące na dystrybucji Debian – ma w sobie całkiem sporo gotowych do instalacji programów. Jest tam np. R i biblioteka ggplot2, możemy więc jednym poleceniem zainstalować je w systemie. Nie ma tam natomiast IDE R Studio, które w przypadku wspomnianych warsztatów okazało się kluczowe. Korzystanie z repozytoriów z oprogramowaniem to jednak sposób pracy głównie w systemie Linux, nie za bardzo sprawdził się w systemie Windows. O Mac OS nie wspominam, bo po dwumiesięcznym obcowaniem z tym systemem jedyne co mi pozostało to wrażenie dziwności. Ale wracając do rzeczy – mamy różne systemy, różne sposoby instalacji i jeden cel – zainstalować R, R Studio i ggplot2. Brzmi jak masa kłopotów. Ale tak nie jest, jeżeli użyjemy platformy Anaconda.
Platforma Anaconda powstała jako odpowiedź między innymi na ten problem. W tym artykule pokażę, jak używając jej, łatwo możemy sobie zorganizować środowisko pracy, niezależnie od systemu operacyjnego (Anaconda działa na systemach Windows, Linux, Mac OS).
Zacznijmy od instalacji. Na stronie Anaconda.org najbardziej eksponowany link prowadzi do miejsca, z którego możemy pobrać pełen instalator dla naszego systemu. Możemy go pobrać, uruchomić i w ten sposób zainstalować Anacondę w naszym systemie. Wraz z Anacondą dostaniemy od razu dostęp do całej masy różnych popularnych bibliotek. Ja jednak nie przepadam za tym sposobem. Wolę zacząć od minimalnej instalacji Anacondy i pobierać sobie to, co jest mi potrzebne w miarę pojawiania się tych potrzeb. Wybieram więc instalator zwany Miniconda. Tak ja w przypadku Anacondy, wybieramy wersję z Pythonem 3, chyba że dokładnie wiemy, co robimy ;-).
Instalacja jest sprowadzona do minimum. Musimy w czasie jej przeprowadzania zaakceptować licencję, wybrać ścieżkę instalacji, i dodać tę ścieżkę do pliku .bashhrc (w przypadku systemu Linux). I tyle. Mamy już w systemie Anacondę, którą możemy użyć do zbudowania naszego środowiska.
Wirtualne środowiska
Pewną nowością dla niektórych czytelników może być koncepcja środowiska wirtualnego. Czyż nie wszystko w komputerze jest wirtualnie? Czy może ma to coś wspólnego z maszynami wirtualnymi? Po co nam to w ogóle?
Ogólna idea instalowania oprogramowania w systemach operacyjnych polega na tym, że instalujemy je w jednej konkretnej wersji i udostępniamy każdemu użytkownikowi komputera. Jeżeli robimy aktualizację oprogramowania, to stara wersja jest odinstalowana i na jej miejsce instalowana jest nowa wersja. I działa to sensownie, jeśli po prostu korzystamy z aplikacji.
W programowaniu niestety sytuacja ma się nieco inaczej. Jeżeli piszemy program, np. w Pythonie albo R to będziemy go zawsze uruchamiać przez interpreter. Interpretery takie mają zawsze swoją wersję. Wersje te mogą się różnić tylko trochę. Ale mogą też wprowadzać tak dużo zmian, że zaczynają egzystować równolegle. Taką sytuację mamy w przypadku Pythona 2 i 3. Niby jest to Python, ale jednak programy pisane pod Pythona 3 prawdopodobnie nie będą działać pod Pythonem 2. Trudno, jakoś trzeba z tym żyć. Prawdziwe problemy zaczynają się jednak przy bibliotekach, z których korzystamy. Możemy sobie wyobrazić sytuację, gdzie korzystamy z biblioteki bib_a. Do działania biblioteka ta wymaga biblioteki bib_b w wersji nie niższej niż 1.5. Wszystkie te biblioteki zainstalowaliśmy sobie w systemie i wszystko działa. Jesteśmy szczęśliwi.
Do czasu. Przychodzi nasz szef i mówi, że startujemy nowy projekt i nie da się go inaczej rozwijać, niż używając biblioteki bib_c. Spoko, myślimy sobie. Instalujemy bibliotekę bib_c a tu klops. Okazuje się, że ta biblioteka wymaga biblioteki bib_b, ale w wersji nie wyższej niż 1.4. Musimy więc odinstalować tę bibliotekę i zainstalować jej wcześniejszą wersję. A jeśli będziemy chcieli wprowadzić i przetestować poprawkę w naszym wcześniejszym projekcie? Będziemy instalować nową wersję, pozbywając się tej starej. I tak praktycznie przez cały czas.
Chyba że użyjemy środowisk wirtualnych. Środowiska takie pozwalają nam wyizolować nasze miejsce pracy, od tego, co jest w systemie. I możemy mieć wiele takich miejsc pracy. Jedno dla starego projektu z odpowiednimi bibliotekami i ich wersjami i drugie dla czegoś nowego, co teoretycznie by nam rozwaliło biblioteki ze starego projektu. Jak zabrać się za coś takiego?
Tworzenie środowiska
Jeśli mamy już zainstalowaną Anacondę, to mamy odpowiedni program, który pomoże nam tworzyć i zarządzać tymi środowiskami. Zacznijmy od stworzenia nowego środowiska na potrzeby np. warsztatów z ggplot2.
W systemie Windows z menu głównego wybieramy pozycję Anaconda Prompt. Otworzy nam się wtedy konsola tekstowa, w której będziemy wpisywać odpowiednie polecenia. Nie ma się czym przejmować, bo tych poleceń nie ma za wiele. Do utworzenia środowiska wystarczy nam jedno polecenie:
conda create -y -n warsztat-ggplot2
W systemie Linux i Mac również użyjemy tego polecenia, wpiszemy je jednak w zwyczajnym terminalu. Co oznaczają poszczególne elementy tego polecenia? Popatrzmy:
- conda – nazwa programu, którego używamy między innymi do zarządzania środowiskami.
- create – działanie które chcemy wykonać. W tym wypadku jest to utworzenie nowego środowiska.
- -y – ustawianie odpowiedzi Tak na wszystkie potencjalne pytania. Używamy tego parametru, jeśli robimy już coś po raz kolejny i dokładnie wiemy, co się wydarzy. W ten sposób nie marnujemy czasu, jeśli zapomnimy spojrzeć na ekran, na którym będzie informacja o oczekiwaniu na nasze działanie.
- -n informujemy program conda o tym, że teraz podamy nazwę naszego środowiska.
- warsztat-ggplot2 – przykładowa nazwa naszego środowiska.
Jak widzimy, nie było to nic trudnego i skomplikowanego :D. Idźmy więc dalej.
Aktywacja środowiska
Po stworzeniu środowiska dostaniemy od razu informację jak je aktywować i dezaktywować. O co w ogóle tu chodzi? Otóż nasze środowisko wirtualne to nie jest np. katalog projektu czy katalog, w którym pracujemy. Jest to sposób na oszukanie systemu operacyjnego. Tak, oszukiwanie systemu to chyba najbliższa analogia odnośnie do tego, co się dzieje, gdy aktywujemy środowisko. O tym za chwilkę.
W systemie Windows w oknie Anaconda Prompt wpisujemy:
conda activate warsztat-ggplot2
W systemach Linux/Mac w terminalu wpisujemy:
source activate warsztat-ggplot2
Sprawdźmy jeszcze składniki tych komend:
- conda – nazwa programu, którego używamy między innymi do aktywacji środowiska.
- source – program obecny w systemach Linux/Mac pozwalający dokonywać wspomnianego „oszustwa”.
- activate – w Windows jest to działanie programu conda, w Linux/Mac jest to nazwa skryptu „oszukującego”.
- warsztat-ggplot2 – przykładowa nazwa naszego środowiska.
W ten sposób dokonujemy aktywacji naszego środowiska. Na początku linii w tej konsoli tekstowej powinien pojawić się nawias z nazwą naszego wirtualnego środowiska, czyli (warsztat-ggplot2). Od tej pory, konsola tekstowa w tym oknie pracuje w oszukanym środowisku. Jeżeli np. będziemy chcieli uruchomić Pythona, to nie uruchomimy Pythona zainstalowanego w systemie, tylko naszego własnego, zainstalowanego przez program conda w naszym własnym środowisku wirtualnym. Jeżeli będziemy coś instalować (przy pomocy programów conda albo pip) wewnątrz tej „oszukanej” konsoli tekstowej to zostanie to zainstalowane w naszym wirtualnym środowisku. Dokonajmy więc takiej instalacji.
Instalacja w środowisku wirtualnym
Upewnijmy się, że w Anaconda Promt albo w terminalu na samym początku miejsca do wpisywania mamy coś w stylu (warsztat-ggplot2). W moim przypadku (Linux) wygląda to tak:
Oznacza to, że jestem w oszukanym środowisku pracy, czyli dokładnie w tym miejscu, w których chcę być. Jak więc instalujemy oprogramowanie w takim miejscu?
conda install -y rstudio
Komenda ta zadziała w taki sam sposób w każdym systemie. Omówmy składowe:
- conda – znany nam już program. Tutaj używamy go do instalacji oprogramowania.
- install – polecenie którym instalujemy oprogramowanie.
- -y – znane już nam potwierdzanie „z góry”.
- rstudio – nazwa pakietu, który chcemy zainstalować.
Sprawdziłem już to wcześniej i wiem, że pakiet rstudio wymusza również instalację samego R, więc w ten sposób skróciłem sobie polecenie. Po wydaniu tego polecenia conda zacznie pobierać odpowiednie pakiety i je instalować. Może to potrwać nawet dłuższą chwilkę.
A co z ggplot2? Okazuje się, że twórcy Anacondy, firma Anaconda Inc. nie wybrała tej biblioteki do dołączenia do oficjalnego i głównego repozytorium. Na szczęście społeczność skupiona wokół Anacondy przygotowała wcale nie gorszą paczkę instalacyjną, która trafiła do dodatkowego repozytorium conda-forge. Aby z niego skorzystać, uruchamiamy:
conda install -y -c conda-forge r-ggplot2
Omówmy nowe elementy:
- -c – parametr, który mówi, że następnie podamy nazwę repozytorium, z którego chcemy skorzystać (c jak channel).
- conda-forge – nazwa naszego repozytorium zarządzanego przez społeczność.
Podobnie jak w sytuacji powyżej, conda pobierze parę pakietów i je zainstaluje. Co dalej?
No właśnie wychodzi na to, że to już koniec. W konsoli tekstowej z aktywowanym wirtualnym środowiskiem wpisujemy rstudio i cieszymy się świeżo zainstalowanym R, R Studio i ggplot2.
Jedna linijka
A gdzie obiecywana jedna linijka? Jest ona powyżej. W kawałkach. Ale możemy ją skleić i uzyskać coś w stylu ściągi, gdy nie mamy głowy do wszystkich tych instalacji. Potrzebujemy tylko mieć zainstalowaną Anacondę (nieważne czy w wersji dużej, czy mini). W wersji Windows w Anaconda Prompt:
conda create -y -n warsztat-ggplot2 && conda activate warsztat-ggplot2 && conda install -y rstudio && conda install -y -c conda-forge r-ggplot2 && rstudio
a w wersji Linux/Mac w terminalu:
conda create -y -n warsztat-ggplot2 && source activate warsztat-ggplot2 && conda install -y rstudio && conda install -y -c conda-forge r-ggplot2 && rstudio
Jeśli będziemy chcieli, powróć do środowiska, w którym pracowaliśmy, wystarczy, że w nowym terminalu wpiszemy:
source activate warsztat-ggplot2 && rstudio
W wersji Windows podmieniamy source na conda.
A o co w ogóle chodzi z tymi znaczkami &&? Dzięki nim możemy łączyć komendy, które wykonują się w trybie tekstowym. Najpierw zostanie wykonane polecenie 1, później polecenie 2 i tak dalej, ale tylko pod warunkiem, że żadne z nich nie zakończyło się błędem. Jeśli dostaniemy jakiś błąd, to ciąg zostanie przerwany. Może tak się czasem zdarzyć, ale to, co tutaj zaproponowałem, nie powinno raczej stwarzać takich problemów. Miłego kodowania w R.
Kursy Online
Jeśli jesteś zainteresowany zakupem wideo kursów online które przygotowałem, sprawdź tę stronę – może akurat opublikowałem tam kupony zniżkowe 🙂
Hej, czy użycie kontenera zamiast anacony nie jest w tej sytuacji bardziej na miejscu?
'docker run -d -p 8787:8787 -e PASSWORD= –name rstudio rocker/rstudio’ i jedziesz 😉 (źródło: https://hub.docker.com/r/rocker/rstudio/)
Powodzenia!
To zależy 🙂
Docker ma niewątpliwe całą masę zalet. Tak jak napisałeś, jeśli mamy na oku odpowiedni obraz to jego uruchomienie jest proste. Pytanie tylko, co z samym dockerem?
Nie wiem, jak teraz to wygląda, ale kiedy ja miałem styczność z dockerem, to na systemach Windows nie za bardzo chciał on działać. A jednak dużo osób używa systemów Windows do pracy w analizie danych.
No i jeszcze problematyczne może być używanie dockera w ograniczonych środowiskach. Anaconda pozwala się instalować lokalnie, docker zdecydowanie mocniej integruje się w systemie, trudno więc może być o dockera np. w zespole analitycznym w banku.
Ale z drugiej strony, jeśli mamy komputer z systemem Linux/Mac i konto admina to może mieć to sens. Szczególnie jeśli korzystamy np. z obrazu przygotowanego przez Kaggle (np. https://hub.docker.com/r/kaggle/python/ albo https://hub.docker.com/r/kaggle/rstats/).
Myślę, że przygotuję artykuł na ten temat.
Dzięki!