Re: [django-cs] Django + Vue = VL? Nebo je to úplně jinak?

[Martin Kubát]

Zdravím,
ano, volba b) je v poslední době běžná. Je tam mnoho a mnoho problémů, ale
také to má své výhody:

   - čistě FE (vue, angular, react,. ...) je špatně čitelný pro roboty
   (některé), je třeba řešit server-side-rendering (firebase, ...)
   - ano, je třeba objevovat kolo hlavně z pohledu routování url adres
   - většinou je třeba dva lidi/týmy - BE/FE.
   - nutnost udržování dokumentace API
   - FE frameworky mají životnost jepice - od začátku psaní tohoto mailu do
   konce bylo určitě vydáno několik main verzí reactu, angularu, npm a
   javascriptu...



   - znovupoužitelnost BE api je super v tom, že se může připojit jak web
   frontend, tak např. mobilní aplikace, nebo prostě nějaký konzument 3.
   strany.
   - člověk se na BE nemusí starat o html/css a řeší jen databázi,
   performance, rest/graphql ... (vyhovuje teda alespoň mě)
   - na tvorbu microservis je to velmi výhodný koncept.
   - ve větším týmu je krásně řešitelné rozdělení rolí (na fullstack
   nevěřím)
   - front je zpravidla rychlejší, tahá se méně dat. UI/UX je možné
   dotáhnout k dokonalosti. Na druhou stranu to žere mnoho více paměti v
   prohlížeči.


Asi bych mohl pokračovat, ale myslím, že základní body jsem napsal.

MK

po 22. 2. 2021 v 21:55 odesílatel Stanislav Vasko 
napsal:

> Zdravím,
>
> stále více mi chybí JS ve frontendu. Prošel jsem si co dneska frčí a
> poměrně jasně jsem si našel Vue jako náplast na moji bolístku. Líbí se mi
> ta reaktivita a naproti ReactJS má víc té “magie” out-of-the-box. Prostě,
> nějak k němu inklinuji, tak snad to není špatná volba.
>
> Takže, pustil jsem se víc do studia, prošel tutoriály, pročetl nějakou tu
> knihu a koukl výuková videa. V podstatě jsem našel 2 možnosti integrace: 1.
> vložit odkaz na Vue.js pro sem-tam využití JS funkce nebo 2. mít ve Vue
> celý frontend, který je na Django zcela nezávislý. Ta druhá cesta je asi
> správná, ale trochu mi vadí/děsí, že se vlastně učím celý další framework a
> naopak všechno “to krásné” z Django je významně zredukováno na něco málo
> víc než prosté ORM a REST API. Navíc deploy znamená neustále řešit
> vystavení 2 nezávislých aplikací, které spolu úzce souvisí.
>
> Chci se jen ujistit, že ORM s REST API + Vue je běžná cesta a opravdu se
> to takto používá. Totiž druhá volba mi připadá nepříjemná ve dvou věcech:
> a) znovuobjevuji kolo, jen místo v Django budu věci dělat ve Vue a
> b) namísto psaní Django aplikace využiji ORM a pak donekonečna na vše
> vytvářím REST API konektory a ve Vue je napojuji.
>
> Neznám JS backendy, ale možná, co já otrocky vytvářím v Django a ručně
> napojuji na Vue (a při změně musím ošetřit/opravit na dvou místech
> nezávisle), bych v JS backendu vyřešil elegantněji? Chci se prostě ujistit,
> že takto to dělají ostatní a neuniká mi nějaké elegantnější řešení.
>
> Díky za tip na lepší řešení či ujištění, že takto je to opravdu správně.
> Uvítám případně i odkazy na tutoriály či knihy, které Vám s Vue pomohly
> nebo je můžete doporučit. Bez JS to prostě u mě dál již nepůjde a tak když
> už, tak pořádně.
>
> Hezký večer, Standa
>
> --
> --
> E-mailová skupina django-cs@googlegroups.com
> Správa: http://groups.google.cz/group/django-cs
> ---
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> „django-cs“ ve Skupinách Google.
> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny,
> zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com.
> Chcete-li tuto diskusi zobrazit na webu, navštivte
> https://groups.google.com/d/msgid/django-cs/CAMD1ck_Bg88W-baXGROKms2LDKyrJOM6E1Kf6dOmcSiQPF7CMQ%40mail.gmail.com
> 
> .
>

-- 
-- 
E-mailová skupina django-cs@googlegroups.com
Správa: http://groups.google.cz/group/django-cs
--- 
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs 
ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete 
e-mail na adresu django-cs+unsubscr...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/CA%2BL8erbVf-bcvHT6m3fuFN073bL%2Bd_yFLFGCEXHxJYxaWGSAGg%40mail.gmail.com.

[django-cs] Django + Vue = VL? Nebo je to úplně jinak?

[Stanislav Vasko]

Zdravím,

stále více mi chybí JS ve frontendu. Prošel jsem si co dneska frčí a
poměrně jasně jsem si našel Vue jako náplast na moji bolístku. Líbí se mi
ta reaktivita a naproti ReactJS má víc té “magie” out-of-the-box. Prostě,
nějak k němu inklinuji, tak snad to není špatná volba.

Takže, pustil jsem se víc do studia, prošel tutoriály, pročetl nějakou tu
knihu a koukl výuková videa. V podstatě jsem našel 2 možnosti integrace: 1.
vložit odkaz na Vue.js pro sem-tam využití JS funkce nebo 2. mít ve Vue
celý frontend, který je na Django zcela nezávislý. Ta druhá cesta je asi
správná, ale trochu mi vadí/děsí, že se vlastně učím celý další framework a
naopak všechno “to krásné” z Django je významně zredukováno na něco málo
víc než prosté ORM a REST API. Navíc deploy znamená neustále řešit
vystavení 2 nezávislých aplikací, které spolu úzce souvisí.

Chci se jen ujistit, že ORM s REST API + Vue je běžná cesta a opravdu se to
takto používá. Totiž druhá volba mi připadá nepříjemná ve dvou věcech:
a) znovuobjevuji kolo, jen místo v Django budu věci dělat ve Vue a
b) namísto psaní Django aplikace využiji ORM a pak donekonečna na vše
vytvářím REST API konektory a ve Vue je napojuji.

Neznám JS backendy, ale možná, co já otrocky vytvářím v Django a ručně
napojuji na Vue (a při změně musím ošetřit/opravit na dvou místech
nezávisle), bych v JS backendu vyřešil elegantněji? Chci se prostě ujistit,
že takto to dělají ostatní a neuniká mi nějaké elegantnější řešení.

Díky za tip na lepší řešení či ujištění, že takto je to opravdu správně.
Uvítám případně i odkazy na tutoriály či knihy, které Vám s Vue pomohly
nebo je můžete doporučit. Bez JS to prostě u mě dál již nepůjde a tak když
už, tak pořádně.

Hezký večer, Standa

-- 
-- 
E-mailová skupina django-cs@googlegroups.com
Správa: http://groups.google.cz/group/django-cs
--- 
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs 
ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete 
e-mail na adresu django-cs+unsubscr...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/CAMD1ck_Bg88W-baXGROKms2LDKyrJOM6E1Kf6dOmcSiQPF7CMQ%40mail.gmail.com.

Re: [django-cs] Jak zjistit jméno projektu

[MirekZv]

@honza

S pydanny/cookiecutterem jsem dělal.
Je to super, pokud člověk potřebuje zjistit, jak uspořádat projekt, jaká 
udělat nastavení a jak je udělat. Pro nějakého samotáře asi skoro jediná 
možnost, jak prakticky začít.
Pokud jsi někde ve firmě, máš navíc možnost obšlehnout firemní uspořádání, 
jak si ho za léta na nějakých jiných projektech vymazlili.

Ale cookiecutter zas jen rozkopírovává šablonu do projektu. Není to reuse. 
Já chci reuse. Nechci to mít 4x a těkat mezi projekty, jestli už jsem i v 
tomhle implementoval to vylepšení, co jsem udělal v jiném.
Jasně, u settings je diskutabilní, jestli si budou mezi projekty podobné 
nebo ne. Můj názor je, že django je natolik brutálně (nechci psát: 
nadbytečně) konfigurovatelné, že většinou pojedeš se stejnými nebo velmi 
podobnými nastaveními. Proto reuse, ne rozkopírování načtyřikrát.

@jakub

Jasně. Ale __file__ je ten soubor, jehož kód právě běží. Pokud je tento 
soubor mimo strom projektu, tak z __file__ nic nezjistíš. Abys měl nějaké 
příklady:
$HOME/.virtualenvs/
$HOME/.cache/pypoetry/virtualenvs/
apod.

@radim

Ty se tam dotýkáš jedné věci, která mě zajímá, ale teď s tím nebudu 
otravovat. Potřebuju už na těch projektech taky popojet, ale časem se asi k 
tomu zeptám.

Díky všem.
Dne pondělí 22. února 2021 v 16:33:15 UTC+1 uživatel honza...@gmail.com 
napsal:

> Jedna z nejvetsich vyhod Djanga je jeho rozsahly ekosystem. Jak uz tady 
> psalo nekolik lidi tak tohle je vyreseny problem. Nez vymyslet vlastni 
> reseni, doporucil bych sahnout k nejake existujici sablone. Ja mam treba 
> rad https://github.com/pydanny/cookiecutter-django ze ktere jsem odvodil 
> i svuj soucasny velky projekt. Resi vsechno vcetne nasazeni do dockeru 
> pokud o to budes stat.
>
>
> Honza Král
> E-Mail: honza...@gmail.com
> Phone:  +420 606 678585 <+420%20606%20678%20585>
>
>
> On Mon, Feb 22, 2021 at 4:30 PM Radim Novotny  wrote:
>
>> Já mám součástí deploymentu (Ansible) nastavení environment var, která 
>> obsahuje cestu, kam se to celé nainstalovalo. 
>> Ostatní settings se odvozují od toho, takže třeba 
>>
>> PROJECT_ROOT = os.environ.get('DJANGO_PROJECT_ROOT')
>> STATIC_ROOT = os.path.join(PROJECT_ROOT, 'static')
>>
>> Navíc tam je i kontrola, aby to fakt bylo nastavený, takže v settings.py 
>> je  
>> if not PROJECT_ROOT:
>> raise ImproperlyConfigured('Environment variable DJANGO_PROJECT_ROOT 
>> is not defined.')
>>
>> Neřeší se, kde je nainstalovaný samotný kód aplikace (python package), 
>> jestli je to venv/src/ nebo venv/lib/python. To mne už samořejmě nezajímá. 
>> Pokud by mne to zajímalo, použiju __file__.
>>
>> Co se týká rozdělení settings, tak je fakt, že jich mám hodně a postupně 
>> se importují. Deployment je zatím vždy na Debian a development je na 
>> Dockeru, takže je to takový šroubovaný, ale všechno je to podchycené buď v 
>> Ansible deploymentu a nebo v konfiguraci Dockeru.
>>
>> Možná ale vlastně potřebuješ úplně něco jinýho :) Přiznávám se, že jsem 
>> se v tom moc nezorientoval.
>>
>> Radim
>>
>> On Mon, Feb 22, 2021 at 4:04 PM Jakub Vysoky  wrote:
>>
>>> Spis pouzij `__file__`
>>>
>>> V `settings.py` si z toho udelat `BASE_DIR` jak pises. `PROJECT_NAME` 
>>> bych ja osobne spis napsal natvrdo, nez takhle magicky odvozoval.
>>>
>>> Na zorganizovani Django settings je vicero projektu a ja momentalne 
>>> nejsem Django mega aktivni, takze nebudu konkretni doporucovat.
>>>
>>> On Mon, Feb 22, 2021 at 3:22 PM MirekZv  wrote:
>>>
 Závěr: Nakonec jsem se příliš bál toho `os.getcwd()` a udělal jsem si 
 tuto funkci:
 ```
 import inspect
 import os
 from pathlib import Path

 def get_project_root():
 for prg in inspect.stack()[::-1]:
 prg = prg.filename
 if '/wsgi.py' in prg or '/asgi.py' in prg:
 return Path(prg).parent.parent
 elif '/manage.py' in prg:
 return Path(prg).parent
 else:
 return Path(os.getcwd())

 BASE_DIR = get_project_root()
 PROJECT_NAME = BASE_DIR.name   # to make some settings portable 
 (DATABASES=..)
 PROJECT_DIR = BASE_DIR / PROJECT_NAME
 ```

 Dne pondělí 22. února 2021 v 15:18:01 UTC+1 uživatel MirekZv napsal:

> @Honza, @starenka
>
> Ahoj chlapi, především díky za vlídné a věcné odpovědi, čekal jsem 
> spíš, že po této otázce už na mě někdo vlítne a pěkně mi vynadá.
>
> Jo, máte přesně pravdu, bylo by to asi lepší (získat to v umístění 
> projektu a předat to nějakým parametrem), než účelu nepřiměřené úsilí, co 
> se s tím snažím dělat.
>
> Přidám nějakou story, jak jsem se do té situace dostal, snad z toho 
> bude něco jasnější, i když osobně jsem nad svým postupem dost na 
> rozpacích:
>
> 1. Nejdřív jsem copy/pastoval ze starého projektu pro vytvoření 
> nového, jak se to asi běžně dělá.
> 2. Pak jsem začal myslet na nějaký reuse, tak jsem si udělal jednu 
> django aplikaci na věci, které 

Re: [django-cs] Jak zjistit jméno projektu

[Honza Král]

Jedna z nejvetsich vyhod Djanga je jeho rozsahly ekosystem. Jak uz tady
psalo nekolik lidi tak tohle je vyreseny problem. Nez vymyslet vlastni
reseni, doporucil bych sahnout k nejake existujici sablone. Ja mam treba
rad https://github.com/pydanny/cookiecutter-django ze ktere jsem odvodil i
svuj soucasny velky projekt. Resi vsechno vcetne nasazeni do dockeru pokud
o to budes stat.


Honza Král
E-Mail: honza.k...@gmail.com
Phone:  +420 606 678585


On Mon, Feb 22, 2021 at 4:30 PM Radim Novotny 
wrote:

> Já mám součástí deploymentu (Ansible) nastavení environment var, která
> obsahuje cestu, kam se to celé nainstalovalo.
> Ostatní settings se odvozují od toho, takže třeba
>
> PROJECT_ROOT = os.environ.get('DJANGO_PROJECT_ROOT')
> STATIC_ROOT = os.path.join(PROJECT_ROOT, 'static')
>
> Navíc tam je i kontrola, aby to fakt bylo nastavený, takže v settings.py
> je
> if not PROJECT_ROOT:
> raise ImproperlyConfigured('Environment variable DJANGO_PROJECT_ROOT
> is not defined.')
>
> Neřeší se, kde je nainstalovaný samotný kód aplikace (python package),
> jestli je to venv/src/ nebo venv/lib/python. To mne už samořejmě nezajímá.
> Pokud by mne to zajímalo, použiju __file__.
>
> Co se týká rozdělení settings, tak je fakt, že jich mám hodně a postupně
> se importují. Deployment je zatím vždy na Debian a development je na
> Dockeru, takže je to takový šroubovaný, ale všechno je to podchycené buď v
> Ansible deploymentu a nebo v konfiguraci Dockeru.
>
> Možná ale vlastně potřebuješ úplně něco jinýho :) Přiznávám se, že jsem se
> v tom moc nezorientoval.
>
> Radim
>
> On Mon, Feb 22, 2021 at 4:04 PM Jakub Vysoky 
> wrote:
>
>> Spis pouzij `__file__`
>>
>> V `settings.py` si z toho udelat `BASE_DIR` jak pises. `PROJECT_NAME`
>> bych ja osobne spis napsal natvrdo, nez takhle magicky odvozoval.
>>
>> Na zorganizovani Django settings je vicero projektu a ja momentalne
>> nejsem Django mega aktivni, takze nebudu konkretni doporucovat.
>>
>> On Mon, Feb 22, 2021 at 3:22 PM MirekZv  wrote:
>>
>>> Závěr: Nakonec jsem se příliš bál toho `os.getcwd()` a udělal jsem si
>>> tuto funkci:
>>> ```
>>> import inspect
>>> import os
>>> from pathlib import Path
>>>
>>> def get_project_root():
>>> for prg in inspect.stack()[::-1]:
>>> prg = prg.filename
>>> if '/wsgi.py' in prg or '/asgi.py' in prg:
>>> return Path(prg).parent.parent
>>> elif '/manage.py' in prg:
>>> return Path(prg).parent
>>> else:
>>> return Path(os.getcwd())
>>>
>>> BASE_DIR = get_project_root()
>>> PROJECT_NAME = BASE_DIR.name   # to make some settings portable
>>> (DATABASES=..)
>>> PROJECT_DIR = BASE_DIR / PROJECT_NAME
>>> ```
>>>
>>> Dne pondělí 22. února 2021 v 15:18:01 UTC+1 uživatel MirekZv napsal:
>>>
 @Honza, @starenka

 Ahoj chlapi, především díky za vlídné a věcné odpovědi, čekal jsem
 spíš, že po této otázce už na mě někdo vlítne a pěkně mi vynadá.

 Jo, máte přesně pravdu, bylo by to asi lepší (získat to v umístění
 projektu a předat to nějakým parametrem), než účelu nepřiměřené úsilí, co
 se s tím snažím dělat.

 Přidám nějakou story, jak jsem se do té situace dostal, snad z toho
 bude něco jasnější, i když osobně jsem nad svým postupem dost na rozpacích:

 1. Nejdřív jsem copy/pastoval ze starého projektu pro vytvoření nového,
 jak se to asi běžně dělá.
 2. Pak jsem začal myslet na nějaký reuse, tak jsem si udělal jednu
 django aplikaci na věci, které by asi byly potřebné ve 2+ projektech.
 3. Pak mě začalo štvát, že tu aplikaci mám pod jednotlivými projekty,
 takže když ji někde změním, neměl bych zapomenout jít i do těch ostatních
 projektů a udělat v ní stejné změny i tam.
 4. Pak jsem tu django aplikaci obecností odkopíroval do adresáře mimo,
 udělal jí vlastní git repozitář, a instaluji ji nějak jako `poetry add
 ../../obecna`
 5. Pak mě začalo štvát, že běžná django settings mají tak 200 řádek
 kódu, stejně jsou vždycky skoro stejná, a když tam něco vylepším, tak zas
 abych šel po projektech a implementoval vylepšení i do ostatních (a nebo v
 tom měl chaos).
 6. Pak jsem si zkusil jakési django-split-settings, rozdělil ten
 mega-file na 10 malých (vypadá to dobře, ale o vhodnosti tohoto mám velké
 pochyby, protože to už jsme možná trochu u zacházení s jmennými prostory
 jako ve Web2py).
 7. Pak jsem většinu nastavení přepsal tak, aby byla obecná, bez
 závislostí na projektu. Příklad: Nemám důvod, proč by se moje postgres
 databáze neměla jmenovat stejně jako projekt. Tak proč psát do nastavení
 natvrdo jméno databáze? - toto je další věc, kterou na Djangu nemám rád, že
 když dělá startproject, tak rozkopíruje po x souborech na y míst jméno
 projektu jako string.
 8. Pak jsem (ze stejných důvodů jako výše) to odsunul mimo ty mé
 projekty.

 Takže: mohl bych si to nastavit v projektech a předat jako parametr.
 Ale čím míň 

Re: [django-cs] Jak zjistit jméno projektu

[Radim Novotny]

Já mám součástí deploymentu (Ansible) nastavení environment var, která
obsahuje cestu, kam se to celé nainstalovalo.
Ostatní settings se odvozují od toho, takže třeba

PROJECT_ROOT = os.environ.get('DJANGO_PROJECT_ROOT')
STATIC_ROOT = os.path.join(PROJECT_ROOT, 'static')

Navíc tam je i kontrola, aby to fakt bylo nastavený, takže v settings.py
je
if not PROJECT_ROOT:
raise ImproperlyConfigured('Environment variable DJANGO_PROJECT_ROOT is
not defined.')

Neřeší se, kde je nainstalovaný samotný kód aplikace (python package),
jestli je to venv/src/ nebo venv/lib/python. To mne už samořejmě nezajímá.
Pokud by mne to zajímalo, použiju __file__.

Co se týká rozdělení settings, tak je fakt, že jich mám hodně a postupně se
importují. Deployment je zatím vždy na Debian a development je na Dockeru,
takže je to takový šroubovaný, ale všechno je to podchycené buď v Ansible
deploymentu a nebo v konfiguraci Dockeru.

Možná ale vlastně potřebuješ úplně něco jinýho :) Přiznávám se, že jsem se
v tom moc nezorientoval.

Radim

On Mon, Feb 22, 2021 at 4:04 PM Jakub Vysoky  wrote:

> Spis pouzij `__file__`
>
> V `settings.py` si z toho udelat `BASE_DIR` jak pises. `PROJECT_NAME` bych
> ja osobne spis napsal natvrdo, nez takhle magicky odvozoval.
>
> Na zorganizovani Django settings je vicero projektu a ja momentalne nejsem
> Django mega aktivni, takze nebudu konkretni doporucovat.
>
> On Mon, Feb 22, 2021 at 3:22 PM MirekZv  wrote:
>
>> Závěr: Nakonec jsem se příliš bál toho `os.getcwd()` a udělal jsem si
>> tuto funkci:
>> ```
>> import inspect
>> import os
>> from pathlib import Path
>>
>> def get_project_root():
>> for prg in inspect.stack()[::-1]:
>> prg = prg.filename
>> if '/wsgi.py' in prg or '/asgi.py' in prg:
>> return Path(prg).parent.parent
>> elif '/manage.py' in prg:
>> return Path(prg).parent
>> else:
>> return Path(os.getcwd())
>>
>> BASE_DIR = get_project_root()
>> PROJECT_NAME = BASE_DIR.name   # to make some settings portable
>> (DATABASES=..)
>> PROJECT_DIR = BASE_DIR / PROJECT_NAME
>> ```
>>
>> Dne pondělí 22. února 2021 v 15:18:01 UTC+1 uživatel MirekZv napsal:
>>
>>> @Honza, @starenka
>>>
>>> Ahoj chlapi, především díky za vlídné a věcné odpovědi, čekal jsem spíš,
>>> že po této otázce už na mě někdo vlítne a pěkně mi vynadá.
>>>
>>> Jo, máte přesně pravdu, bylo by to asi lepší (získat to v umístění
>>> projektu a předat to nějakým parametrem), než účelu nepřiměřené úsilí, co
>>> se s tím snažím dělat.
>>>
>>> Přidám nějakou story, jak jsem se do té situace dostal, snad z toho bude
>>> něco jasnější, i když osobně jsem nad svým postupem dost na rozpacích:
>>>
>>> 1. Nejdřív jsem copy/pastoval ze starého projektu pro vytvoření nového,
>>> jak se to asi běžně dělá.
>>> 2. Pak jsem začal myslet na nějaký reuse, tak jsem si udělal jednu
>>> django aplikaci na věci, které by asi byly potřebné ve 2+ projektech.
>>> 3. Pak mě začalo štvát, že tu aplikaci mám pod jednotlivými projekty,
>>> takže když ji někde změním, neměl bych zapomenout jít i do těch ostatních
>>> projektů a udělat v ní stejné změny i tam.
>>> 4. Pak jsem tu django aplikaci obecností odkopíroval do adresáře mimo,
>>> udělal jí vlastní git repozitář, a instaluji ji nějak jako `poetry add
>>> ../../obecna`
>>> 5. Pak mě začalo štvát, že běžná django settings mají tak 200 řádek
>>> kódu, stejně jsou vždycky skoro stejná, a když tam něco vylepším, tak zas
>>> abych šel po projektech a implementoval vylepšení i do ostatních (a nebo v
>>> tom měl chaos).
>>> 6. Pak jsem si zkusil jakési django-split-settings, rozdělil ten
>>> mega-file na 10 malých (vypadá to dobře, ale o vhodnosti tohoto mám velké
>>> pochyby, protože to už jsme možná trochu u zacházení s jmennými prostory
>>> jako ve Web2py).
>>> 7. Pak jsem většinu nastavení přepsal tak, aby byla obecná, bez
>>> závislostí na projektu. Příklad: Nemám důvod, proč by se moje postgres
>>> databáze neměla jmenovat stejně jako projekt. Tak proč psát do nastavení
>>> natvrdo jméno databáze? - toto je další věc, kterou na Djangu nemám rád, že
>>> když dělá startproject, tak rozkopíruje po x souborech na y míst jméno
>>> projektu jako string.
>>> 8. Pak jsem (ze stejných důvodů jako výše) to odsunul mimo ty mé
>>> projekty.
>>>
>>> Takže: mohl bych si to nastavit v projektech a předat jako parametr. Ale
>>> čím míň toho zůstane customizovaného pro projekty, tím lépe.
>>> Navíc to django-split-settings se volá pomocí jakýchsi funkcí include()
>>> a optional() a nejsem si tak úplně jistý, jak snadno tam jdou parametry
>>> předávat.
>>>
>>> Dne pondělí 22. února 2021 v 14:58:03 UTC+1 uživatel MirekZv napsal:
>>>
 @John

 Jo, zase jsem horlivější než je vhodné.
 Nemyslel jsem to tak, že já sám chci mít na stagingu/produkci/.. různá
 prostředí.
 Myslel jsem to tak, že kdyby se to někdy z nějakých nyní neznámých
 důvodů ocitlo pod jiným prostředím (např. na různých cloudech), aby to
 chodilo.
 Čili přehnaná 

Re: [django-cs] Jak zjistit jméno projektu

[Jakub Vysoky]

Spis pouzij `__file__`

V `settings.py` si z toho udelat `BASE_DIR` jak pises. `PROJECT_NAME` bych
ja osobne spis napsal natvrdo, nez takhle magicky odvozoval.

Na zorganizovani Django settings je vicero projektu a ja momentalne nejsem
Django mega aktivni, takze nebudu konkretni doporucovat.

On Mon, Feb 22, 2021 at 3:22 PM MirekZv  wrote:

> Závěr: Nakonec jsem se příliš bál toho `os.getcwd()` a udělal jsem si tuto
> funkci:
> ```
> import inspect
> import os
> from pathlib import Path
>
> def get_project_root():
> for prg in inspect.stack()[::-1]:
> prg = prg.filename
> if '/wsgi.py' in prg or '/asgi.py' in prg:
> return Path(prg).parent.parent
> elif '/manage.py' in prg:
> return Path(prg).parent
> else:
> return Path(os.getcwd())
>
> BASE_DIR = get_project_root()
> PROJECT_NAME = BASE_DIR.name   # to make some settings portable
> (DATABASES=..)
> PROJECT_DIR = BASE_DIR / PROJECT_NAME
> ```
>
> Dne pondělí 22. února 2021 v 15:18:01 UTC+1 uživatel MirekZv napsal:
>
>> @Honza, @starenka
>>
>> Ahoj chlapi, především díky za vlídné a věcné odpovědi, čekal jsem spíš,
>> že po této otázce už na mě někdo vlítne a pěkně mi vynadá.
>>
>> Jo, máte přesně pravdu, bylo by to asi lepší (získat to v umístění
>> projektu a předat to nějakým parametrem), než účelu nepřiměřené úsilí, co
>> se s tím snažím dělat.
>>
>> Přidám nějakou story, jak jsem se do té situace dostal, snad z toho bude
>> něco jasnější, i když osobně jsem nad svým postupem dost na rozpacích:
>>
>> 1. Nejdřív jsem copy/pastoval ze starého projektu pro vytvoření nového,
>> jak se to asi běžně dělá.
>> 2. Pak jsem začal myslet na nějaký reuse, tak jsem si udělal jednu django
>> aplikaci na věci, které by asi byly potřebné ve 2+ projektech.
>> 3. Pak mě začalo štvát, že tu aplikaci mám pod jednotlivými projekty,
>> takže když ji někde změním, neměl bych zapomenout jít i do těch ostatních
>> projektů a udělat v ní stejné změny i tam.
>> 4. Pak jsem tu django aplikaci obecností odkopíroval do adresáře mimo,
>> udělal jí vlastní git repozitář, a instaluji ji nějak jako `poetry add
>> ../../obecna`
>> 5. Pak mě začalo štvát, že běžná django settings mají tak 200 řádek kódu,
>> stejně jsou vždycky skoro stejná, a když tam něco vylepším, tak zas abych
>> šel po projektech a implementoval vylepšení i do ostatních (a nebo v tom
>> měl chaos).
>> 6. Pak jsem si zkusil jakési django-split-settings, rozdělil ten
>> mega-file na 10 malých (vypadá to dobře, ale o vhodnosti tohoto mám velké
>> pochyby, protože to už jsme možná trochu u zacházení s jmennými prostory
>> jako ve Web2py).
>> 7. Pak jsem většinu nastavení přepsal tak, aby byla obecná, bez
>> závislostí na projektu. Příklad: Nemám důvod, proč by se moje postgres
>> databáze neměla jmenovat stejně jako projekt. Tak proč psát do nastavení
>> natvrdo jméno databáze? - toto je další věc, kterou na Djangu nemám rád, že
>> když dělá startproject, tak rozkopíruje po x souborech na y míst jméno
>> projektu jako string.
>> 8. Pak jsem (ze stejných důvodů jako výše) to odsunul mimo ty mé projekty.
>>
>> Takže: mohl bych si to nastavit v projektech a předat jako parametr. Ale
>> čím míň toho zůstane customizovaného pro projekty, tím lépe.
>> Navíc to django-split-settings se volá pomocí jakýchsi funkcí include() a
>> optional() a nejsem si tak úplně jistý, jak snadno tam jdou parametry
>> předávat.
>>
>> Dne pondělí 22. února 2021 v 14:58:03 UTC+1 uživatel MirekZv napsal:
>>
>>> @John
>>>
>>> Jo, zase jsem horlivější než je vhodné.
>>> Nemyslel jsem to tak, že já sám chci mít na stagingu/produkci/.. různá
>>> prostředí.
>>> Myslel jsem to tak, že kdyby se to někdy z nějakých nyní neznámých
>>> důvodů ocitlo pod jiným prostředím (např. na různých cloudech), aby to
>>> chodilo.
>>> Čili přehnaná snaha o obecnost, která se nakonec skoro vždycky spíš
>>> vymstí.
>>>
>>> Jinak vyvíjím i nasazuji na poslední Debian, takže vlastně skoro
>>> identické prostředí na vývoji i produkci.
>>> Díky tedy za doporučení dockeru, já už jsem si s ním kdysi pohrával, ale
>>> zjistil jsem, že pro laika to zas tak ultrasnadné není,
>>> pak se mi zdá, že to docela žere místo na disku (zvlášť když tam
>>> zapomeneš něco nesmazaného z předchozích pokusů), což při nasazování na
>>> (cizí=veřejný) virtuální server je dost zásadní,
>>> a pak, když to jedu vše na Debianu, tak by ten přínos zas tak zásadní
>>> nebyl.
>>> Takže Docker je zatím odložen.
>>>
>>> Dne pátek 19. února 2021 v 22:59:35 UTC+1 uživatel starenka napsal:
>>>
 A kdyz to teda volas z toho prokektu, proc to ty fci v tom modulu
 nepredas jako arg?


 On Fri, Feb 19, 2021, 22:51 Jan Bednařík  wrote:

> A nemůžeš mít název toho projektu jako konstantu přímo v settings?
> Zjišťovat to z názvu adresáře mi přijde příliš křehké.
>
> A Sites znáš? to je takovej dobrej způsob, jak pracovat s více
> projekty / instalacemi / weby v jedné code base:
> 

Re: [django-cs] Jak zjistit jméno projektu

[MirekZv]

Závěr: Nakonec jsem se příliš bál toho `os.getcwd()` a udělal jsem si tuto 
funkci:
```
import inspect
import os
from pathlib import Path

def get_project_root():
for prg in inspect.stack()[::-1]:
prg = prg.filename
if '/wsgi.py' in prg or '/asgi.py' in prg:
return Path(prg).parent.parent
elif '/manage.py' in prg:
return Path(prg).parent
else:
return Path(os.getcwd())

BASE_DIR = get_project_root()
PROJECT_NAME = BASE_DIR.name   # to make some settings portable 
(DATABASES=..)
PROJECT_DIR = BASE_DIR / PROJECT_NAME
```

Dne pondělí 22. února 2021 v 15:18:01 UTC+1 uživatel MirekZv napsal:

> @Honza, @starenka
>
> Ahoj chlapi, především díky za vlídné a věcné odpovědi, čekal jsem spíš, 
> že po této otázce už na mě někdo vlítne a pěkně mi vynadá.
>
> Jo, máte přesně pravdu, bylo by to asi lepší (získat to v umístění 
> projektu a předat to nějakým parametrem), než účelu nepřiměřené úsilí, co 
> se s tím snažím dělat.
>
> Přidám nějakou story, jak jsem se do té situace dostal, snad z toho bude 
> něco jasnější, i když osobně jsem nad svým postupem dost na rozpacích:
>
> 1. Nejdřív jsem copy/pastoval ze starého projektu pro vytvoření nového, 
> jak se to asi běžně dělá.
> 2. Pak jsem začal myslet na nějaký reuse, tak jsem si udělal jednu django 
> aplikaci na věci, které by asi byly potřebné ve 2+ projektech.
> 3. Pak mě začalo štvát, že tu aplikaci mám pod jednotlivými projekty, 
> takže když ji někde změním, neměl bych zapomenout jít i do těch ostatních 
> projektů a udělat v ní stejné změny i tam.
> 4. Pak jsem tu django aplikaci obecností odkopíroval do adresáře mimo, 
> udělal jí vlastní git repozitář, a instaluji ji nějak jako `poetry add 
> ../../obecna`
> 5. Pak mě začalo štvát, že běžná django settings mají tak 200 řádek kódu, 
> stejně jsou vždycky skoro stejná, a když tam něco vylepším, tak zas abych 
> šel po projektech a implementoval vylepšení i do ostatních (a nebo v tom 
> měl chaos).
> 6. Pak jsem si zkusil jakési django-split-settings, rozdělil ten mega-file 
> na 10 malých (vypadá to dobře, ale o vhodnosti tohoto mám velké pochyby, 
> protože to už jsme možná trochu u zacházení s jmennými prostory jako ve 
> Web2py).
> 7. Pak jsem většinu nastavení přepsal tak, aby byla obecná, bez závislostí 
> na projektu. Příklad: Nemám důvod, proč by se moje postgres databáze neměla 
> jmenovat stejně jako projekt. Tak proč psát do nastavení natvrdo jméno 
> databáze? - toto je další věc, kterou na Djangu nemám rád, že když dělá 
> startproject, tak rozkopíruje po x souborech na y míst jméno projektu jako 
> string.
> 8. Pak jsem (ze stejných důvodů jako výše) to odsunul mimo ty mé projekty.
>
> Takže: mohl bych si to nastavit v projektech a předat jako parametr. Ale 
> čím míň toho zůstane customizovaného pro projekty, tím lépe.
> Navíc to django-split-settings se volá pomocí jakýchsi funkcí include() a 
> optional() a nejsem si tak úplně jistý, jak snadno tam jdou parametry 
> předávat.
>
> Dne pondělí 22. února 2021 v 14:58:03 UTC+1 uživatel MirekZv napsal:
>
>> @John
>>
>> Jo, zase jsem horlivější než je vhodné.
>> Nemyslel jsem to tak, že já sám chci mít na stagingu/produkci/.. různá 
>> prostředí.
>> Myslel jsem to tak, že kdyby se to někdy z nějakých nyní neznámých důvodů 
>> ocitlo pod jiným prostředím (např. na různých cloudech), aby to chodilo.
>> Čili přehnaná snaha o obecnost, která se nakonec skoro vždycky spíš 
>> vymstí.
>>
>> Jinak vyvíjím i nasazuji na poslední Debian, takže vlastně skoro 
>> identické prostředí na vývoji i produkci.
>> Díky tedy za doporučení dockeru, já už jsem si s ním kdysi pohrával, ale 
>> zjistil jsem, že pro laika to zas tak ultrasnadné není,
>> pak se mi zdá, že to docela žere místo na disku (zvlášť když tam 
>> zapomeneš něco nesmazaného z předchozích pokusů), což při nasazování na 
>> (cizí=veřejný) virtuální server je dost zásadní,
>> a pak, když to jedu vše na Debianu, tak by ten přínos zas tak zásadní 
>> nebyl.
>> Takže Docker je zatím odložen.
>>
>> Dne pátek 19. února 2021 v 22:59:35 UTC+1 uživatel starenka napsal:
>>
>>> A kdyz to teda volas z toho prokektu, proc to ty fci v tom modulu 
>>> nepredas jako arg? 
>>>
>>>
>>> On Fri, Feb 19, 2021, 22:51 Jan Bednařík  wrote:
>>>
 A nemůžeš mít název toho projektu jako konstantu přímo v settings? 
 Zjišťovat to z názvu adresáře mi přijde příliš křehké.

 A Sites znáš? to je takovej dobrej způsob, jak pracovat s více projekty 
 / instalacemi / weby v jedné code base: 
 https://docs.djangoproject.com/en/3.1/ref/contrib/sites/

 Honza

 pá 19. 2. 2021 v 19:50 odesílatel Jan Walter  napsal:

> Asi nejsem sto se přesně naladit na charakter Tvého problému, ale 
> pokud mohu poradit obecně, snažil bych se vystříhat tomu, aby "bylo na 
> produkci pokaždé něco jinak".
>
> My v partě máme oblíbený docker, což je technologie využitelná např. 
> na to, aby bylo, pokud možno, "všude všechno v 

Re: [django-cs] Jak zjistit jméno projektu

[MirekZv]

@Honza, @starenka

Ahoj chlapi, především díky za vlídné a věcné odpovědi, čekal jsem spíš, že 
po této otázce už na mě někdo vlítne a pěkně mi vynadá.

Jo, máte přesně pravdu, bylo by to asi lepší (získat to v umístění projektu 
a předat to nějakým parametrem), než účelu nepřiměřené úsilí, co se s tím 
snažím dělat.

Přidám nějakou story, jak jsem se do té situace dostal, snad z toho bude 
něco jasnější, i když osobně jsem nad svým postupem dost na rozpacích:

1. Nejdřív jsem copy/pastoval ze starého projektu pro vytvoření nového, jak 
se to asi běžně dělá.
2. Pak jsem začal myslet na nějaký reuse, tak jsem si udělal jednu django 
aplikaci na věci, které by asi byly potřebné ve 2+ projektech.
3. Pak mě začalo štvát, že tu aplikaci mám pod jednotlivými projekty, takže 
když ji někde změním, neměl bych zapomenout jít i do těch ostatních 
projektů a udělat v ní stejné změny i tam.
4. Pak jsem tu django aplikaci obecností odkopíroval do adresáře mimo, 
udělal jí vlastní git repozitář, a instaluji ji nějak jako `poetry add 
../../obecna`
5. Pak mě začalo štvát, že běžná django settings mají tak 200 řádek kódu, 
stejně jsou vždycky skoro stejná, a když tam něco vylepším, tak zas abych 
šel po projektech a implementoval vylepšení i do ostatních (a nebo v tom 
měl chaos).
6. Pak jsem si zkusil jakési django-split-settings, rozdělil ten mega-file 
na 10 malých (vypadá to dobře, ale o vhodnosti tohoto mám velké pochyby, 
protože to už jsme možná trochu u zacházení s jmennými prostory jako ve 
Web2py).
7. Pak jsem většinu nastavení přepsal tak, aby byla obecná, bez závislostí 
na projektu. Příklad: Nemám důvod, proč by se moje postgres databáze neměla 
jmenovat stejně jako projekt. Tak proč psát do nastavení natvrdo jméno 
databáze? - toto je další věc, kterou na Djangu nemám rád, že když dělá 
startproject, tak rozkopíruje po x souborech na y míst jméno projektu jako 
string.
8. Pak jsem (ze stejných důvodů jako výše) to odsunul mimo ty mé projekty.

Takže: mohl bych si to nastavit v projektech a předat jako parametr. Ale 
čím míň toho zůstane customizovaného pro projekty, tím lépe.
Navíc to django-split-settings se volá pomocí jakýchsi funkcí include() a 
optional() a nejsem si tak úplně jistý, jak snadno tam jdou parametry 
předávat.

Dne pondělí 22. února 2021 v 14:58:03 UTC+1 uživatel MirekZv napsal:

> @John
>
> Jo, zase jsem horlivější než je vhodné.
> Nemyslel jsem to tak, že já sám chci mít na stagingu/produkci/.. různá 
> prostředí.
> Myslel jsem to tak, že kdyby se to někdy z nějakých nyní neznámých důvodů 
> ocitlo pod jiným prostředím (např. na různých cloudech), aby to chodilo.
> Čili přehnaná snaha o obecnost, která se nakonec skoro vždycky spíš vymstí.
>
> Jinak vyvíjím i nasazuji na poslední Debian, takže vlastně skoro identické 
> prostředí na vývoji i produkci.
> Díky tedy za doporučení dockeru, já už jsem si s ním kdysi pohrával, ale 
> zjistil jsem, že pro laika to zas tak ultrasnadné není,
> pak se mi zdá, že to docela žere místo na disku (zvlášť když tam zapomeneš 
> něco nesmazaného z předchozích pokusů), což při nasazování na 
> (cizí=veřejný) virtuální server je dost zásadní,
> a pak, když to jedu vše na Debianu, tak by ten přínos zas tak zásadní 
> nebyl.
> Takže Docker je zatím odložen.
>
> Dne pátek 19. února 2021 v 22:59:35 UTC+1 uživatel starenka napsal:
>
>> A kdyz to teda volas z toho prokektu, proc to ty fci v tom modulu 
>> nepredas jako arg? 
>>
>>
>> On Fri, Feb 19, 2021, 22:51 Jan Bednařík  wrote:
>>
>>> A nemůžeš mít název toho projektu jako konstantu přímo v settings? 
>>> Zjišťovat to z názvu adresáře mi přijde příliš křehké.
>>>
>>> A Sites znáš? to je takovej dobrej způsob, jak pracovat s více projekty 
>>> / instalacemi / weby v jedné code base: 
>>> https://docs.djangoproject.com/en/3.1/ref/contrib/sites/
>>>
>>> Honza
>>>
>>> pá 19. 2. 2021 v 19:50 odesílatel Jan Walter  napsal:
>>>
 Asi nejsem sto se přesně naladit na charakter Tvého problému, ale pokud 
 mohu poradit obecně, snažil bych se vystříhat tomu, aby "bylo na produkci 
 pokaždé něco jinak".

 My v partě máme oblíbený docker, což je technologie využitelná např. na 
 to, aby bylo, pokud možno, "všude všechno v základu stejně". Doporučuji 
 Tvé 
 pozornosti.

 John

 On Fri, 19 Feb 2021, 19:32 MirekZv,  wrote:

> Běží mi kód ve stacku projektu,
> ale dotyčný soubor se nachází mimo adresář projektu.
> Jak bych zjistil jméno projektu?
>
> Abych to trochu vysvětlil:
> V běžných django settings se řeší přesně toto, co potřebuju, třeba 
> nějak přibližně takto:
> BASE_DIR = Path(__file__).resolve().parent.parent
> PROJECT_NAME = BASE_DIR.name
>
> Potřebuju totéž zjistit v souboru, který není v BASE_DIR.
> A to tak, že nechci nic nastavovat nikde v souborech pod BASE_DIR.
>
> Napadají mě 2 možnosti:
> - zjistit to nějak z inspect.stack() --ale nevím, jak to udělat dost 
> bezpečně
> - vzít jenom 

Re: [django-cs] Jak zjistit jméno projektu

[MirekZv]

@John

Jo, zase jsem horlivější než je vhodné.
Nemyslel jsem to tak, že já sám chci mít na stagingu/produkci/.. různá 
prostředí.
Myslel jsem to tak, že kdyby se to někdy z nějakých nyní neznámých důvodů 
ocitlo pod jiným prostředím (např. na různých cloudech), aby to chodilo.
Čili přehnaná snaha o obecnost, která se nakonec skoro vždycky spíš vymstí.

Jinak vyvíjím i nasazuji na poslední Debian, takže vlastně skoro identické 
prostředí na vývoji i produkci.
Díky tedy za doporučení dockeru, já už jsem si s ním kdysi pohrával, ale 
zjistil jsem, že pro laika to zas tak ultrasnadné není,
pak se mi zdá, že to docela žere místo na disku (zvlášť když tam zapomeneš 
něco nesmazaného z předchozích pokusů), což při nasazování na 
(cizí=veřejný) virtuální server je dost zásadní,
a pak, když to jedu vše na Debianu, tak by ten přínos zas tak zásadní nebyl.
Takže Docker je zatím odložen.

Dne pátek 19. února 2021 v 22:59:35 UTC+1 uživatel starenka napsal:

> A kdyz to teda volas z toho prokektu, proc to ty fci v tom modulu nepredas 
> jako arg? 
>
>
> On Fri, Feb 19, 2021, 22:51 Jan Bednařík  wrote:
>
>> A nemůžeš mít název toho projektu jako konstantu přímo v settings? 
>> Zjišťovat to z názvu adresáře mi přijde příliš křehké.
>>
>> A Sites znáš? to je takovej dobrej způsob, jak pracovat s více projekty / 
>> instalacemi / weby v jedné code base: 
>> https://docs.djangoproject.com/en/3.1/ref/contrib/sites/
>>
>> Honza
>>
>> pá 19. 2. 2021 v 19:50 odesílatel Jan Walter  napsal:
>>
>>> Asi nejsem sto se přesně naladit na charakter Tvého problému, ale pokud 
>>> mohu poradit obecně, snažil bych se vystříhat tomu, aby "bylo na produkci 
>>> pokaždé něco jinak".
>>>
>>> My v partě máme oblíbený docker, což je technologie využitelná např. na 
>>> to, aby bylo, pokud možno, "všude všechno v základu stejně". Doporučuji Tvé 
>>> pozornosti.
>>>
>>> John
>>>
>>> On Fri, 19 Feb 2021, 19:32 MirekZv,  wrote:
>>>
 Běží mi kód ve stacku projektu,
 ale dotyčný soubor se nachází mimo adresář projektu.
 Jak bych zjistil jméno projektu?

 Abych to trochu vysvětlil:
 V běžných django settings se řeší přesně toto, co potřebuju, třeba 
 nějak přibližně takto:
 BASE_DIR = Path(__file__).resolve().parent.parent
 PROJECT_NAME = BASE_DIR.name

 Potřebuju totéž zjistit v souboru, který není v BASE_DIR.
 A to tak, že nechci nic nastavovat nikde v souborech pod BASE_DIR.

 Napadají mě 2 možnosti:
 - zjistit to nějak z inspect.stack() --ale nevím, jak to udělat dost 
 bezpečně
 - vzít jenom os.getcwd() --za předpokladu, že mám úplně standardní 
 projekt, se stejným jménem rootu i adresáře projektu

 Zatím jsem se spokojil s tím posledním.
 Myslíte, že by na to mohl být spoleh ve všech variantách na produkci?

 Alternativně: Dá se nějak snadno zjistit z kódu settings file (protože 
 ten mám pod projektem; nebo prostě jakýkoli file, který je bezpečně pod 
 adresářem projektu (např. ve stacku mám jako první manage.py, jenže to asi 
 na produkci bude pokaždé jinak).

 Díky, tedy kdyby někdo věděl.

 -- 
 -- 
 E-mailová skupina djan...@googlegroups.com
 Správa: http://groups.google.cz/group/django-cs
 --- 
 Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny 
 „django-cs“ ve Skupinách Google.
 Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, 
 zašlete e-mail na adresu django-cs+...@googlegroups.com.
 Chcete-li tuto diskusi zobrazit na webu, navštivte 
 https://groups.google.com/d/msgid/django-cs/2c569772-cc17-437d-80ec-0411a0207c33n%40googlegroups.com
  
 
 .

>>> -- 
>>> -- 
>>> E-mailová skupina djan...@googlegroups.com
>>> Správa: http://groups.google.cz/group/django-cs
>>> --- 
>>> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny 
>>> „django-cs“ ve Skupinách Google.
>>> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, 
>>> zašlete e-mail na adresu django-cs+...@googlegroups.com.
>>> Chcete-li tuto diskusi zobrazit na webu, navštivte 
>>> https://groups.google.com/d/msgid/django-cs/CAK-vJU%3D6zQW99QbNdrXSC7jGxNVxEB7y39M%2BDYUi%3DJQMG_MwLA%40mail.gmail.com
>>>  
>>> 
>>> .
>>>
>> -- 
>> -- 
>> E-mailová skupina djan...@googlegroups.com
>> Správa: http://groups.google.cz/group/django-cs
>> --- 
>> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny 
>> „django-cs“ ve Skupinách Google.
>> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, 
>> zašlete e-mail na adresu django-cs+...@googlegroups.com.
>>
> Chcete-li tuto diskusi zobrazit na webu, navštivte 
>>