Witam
Mam pytanko do bardziej doświadczonych programistów w kwestii pracowania nad kodem. Tworzę aplikację Django, który ma już całkiem spore rozmiary i powoli zaczynam się gubić w pewnych kwestiach. Pracuję na localhoscie i tam wszystko testuję, następnie przerzucam wszystko na serwer produkcyjny gdzie działa już właściwy projekt. Mam dwa różne pliki ```
settings.py
A Django nie ma jakiegoś rozwiązania w tym celu?
W Ruby on Rails na przykład są specjalne środowiska (environments), które można równolegle ze sobą skonfigurować:
http://guides.rubyonrails.org/configuring.html#creating-rails-environments
możliwe, że Django też coś będzie takiego miało (ale w Django bardzo dawno temu pisałem).
A Django nie ma jakiegoś rozwiązania w tym celu?
Nic mi na ten temat nie wiadomo. Wydaje mi się, że najsensowniejszym rozwiązaniem byłoby nauczenie się pracy na gałęziach gita. Wtedy miałbym dajmy na to 3 wersje programu. I scalał bym te modyfikacje, które dla danej wersji byłyby odpowiednie.
PIERWSZY link po wpisaniu w Google django settings.py multiple environments.
Poczytam. Dzięki.
Powinieneś mieć jakić plik w stylu example.env i w nim wszystko co może być użyte, a do tego w każdym środowisku osobny plik .env który to jest w ignorowanych dla gita, ustawiasz go ręcznie na serwerze kopiując plik example.env i zmieniając w nim wartości. To jest przykład rozwiązania z tak nienawidzonego przez pythonowców php a dokładniej z laravela, więc wątpie, żeby się nie dało zrobić podobnie w pythonie.
Co do gita to bez dwóch zdań powinieneś pracować na wielu branch'ach :D.
Obczaj sobie Successful git branching model
Pracuje i pracowałem w niejednym projekcie za pomocą tego modelu i bardzo sobie chwalę :).
Dzięki za podopowiedzi. Wydaje mi się, że sposób wskazany przez @MichalTHEDUDE jest chyba najwłaściwszy dla moich problemów. Program piszę samodzielnie, nie mam publicznego repozytorium, także nie obawiam się o wyciek danych w różnych settingsach. Po prostu tworzę jeden projekt, ale czasem potrzebuję np. żeby wersja demo była okrojona o jakieś funkcjonalności (np. brak możliwości skasowania konkretnego użytkownika). Jednym słowem powinna zawierać wszystko co jest w branchu master z małą modyfikacją i swoim plikiem ```
settings.py
jak jeszcze powiesz, że trzymasz dane logowania do bazy etc w repo to pogratulować... Jeden z największych błędów bezpieczeństwa jakie można popełnić.
jak jeszcze powiesz, że trzymasz dane logowania do bazy etc w repo to pogratulować...
Repozytorium trzymam wyłącznie lokalnie. Chodzi Ci o to żeby ogólnie pliki settings czy inne zawierające dane logowania w ogóle nie były ujmowane przez GITa?
Aha czyli nie korzystasz z githuba/bitbucketa/etc. ? No to też pięknie padnie ci dysk i wsiu nie ma projektu :D
No to też pięknie padnie ci dysk i wsiu nie ma projektu :D
Jak padnie to będzie gdzie indziej. Kopia jest. O to się nie martw.
Fajnie ale po to jest właśnie git, żeby repo trzymać zdalnie i mieć dostep z każdego miejsca i kompa do niego. Deeploy w takim wypadku też jest prosty, jedna komenda na serwerze i wszystko co potrzebne wgrane.
mr_jaro napisał(a):
Fajnie ale po to jest właśnie git, żeby repo trzymać zdalnie i mieć dostep z każdego miejsca i kompa do niego. Deeploy w takim wypadku też jest prosty, jedna komenda na serwerze i wszystko co potrzebne wgrane.
Ok. Ja mam dostęp na zasadzie synchronizacji poprzez Dropboxa. U mnie się sprawdza. Zmieniam komputer i mam to samo co na głównym. Tylko tak jak mówiłem wcześniej pracuję nad tym sam i nie udostępniam nikomu kodu. To pytanie z innej beczki. Jak rozwiązujesz problem plików zawierających właśnie dane logowania (np. w Djangowym ```
settings.py
nie pisze w pythonie ale wiem, że pliki środowiskowe są tam tak samo dostępne jak i w innych językach, zresztą opisałem ci na przykładzie laravela jak to się robi. Takiego pliku środowiskowego nie trzymam na repo, na repo trzymam wzór i na konkretne maszynie ten wzór kopiuje, ustawiam odpowiednią nazwę i ustawiam wartości w tym dane logowania do baz.
Edit: proszę bardzo https://github.com/theskumar/python-dotenv