Jak zjistit jméno projektu

[MirekZv]

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.

[MirekZv]

Zeptám se lépe: Jak může obecná package zjistit jméno nebo adresář projektu, z něhož je zavolána?

Dne pátek 19. února 2021 v 19:32:36 UTC+1 uživatel MirekZv napsal:

[MirekZv]

PS: dokud nejsou vyhodnoceny settings; tedy obecná package, která má něco připravit pro vyhodnocení těch settings.

Dne pátek 19. února 2021 v 19:41:30 UTC+1 uživatel MirekZv napsal:

[Jan Walter]

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

--
--
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.

[Jan Bednařík]

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 <jnw...@gmail.com> napsal:

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.

[starenka .]

A kdyz to teda volas z toho prokektu, proc to ty fci v tom modulu nepredas jako arg? 

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/CAMmgUkNE8pvmhtkfV2VaN_cmzdB1WytZSMev-tbW9KyuBbOEog%40mail.gmail.com.

[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:

[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:

[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:

[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.

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/c00991f9-4c8c-49af-8b48-0a5a09865b68n%40googlegroups.com.

--

Jakub Vysoky

mob: +420 605 852 377
jab: jakub....@gmail.com
twit: https://twitter.com/kvbik

[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

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/CAEO8NYxNcLRFtAL-LMLDjGL7q%3D1qLtm4nGYqO-2gP4HYScPFGg%40mail.gmail.com.

[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...@gmail.com
Phone:  +420 606 678585

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/CADDKcsurJP0jNTR%2BckEF%2BiiyqgDryDcCZ-3kpcjWx_3bC7gBwg%40mail.gmail.com.

[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:

[Jan Bednařík]

Na konfiguraci z ENV proměnných doporučuji django-environ https://django-environ.readthedocs.io/en/latest/

Honza

po 22. 2. 2021 v 20:14 odesílatel MirekZv <mirek....@gmail.com> napsal:

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/79d6ee77-3d93-4c80-be82-0d84cc2c3ba3n%40googlegroups.com.

[Jakub Vysoky]

Ve __file__ je i cesta v modulu. Takze ja jsem si to konstruoval napr v settings. 

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/79d6ee77-3d93-4c80-be82-0d84cc2c3ba3n%40googlegroups.com.

[MirekZv]

@jakub

Ahoj Jakube. Čteš i co jsem Ti napsal? Trochu Tě podezírám, že ne. Nebo Ti nerozumím.

Já to umím zkonstruovat z __file__, ale když je to v package, která je někde ve virtualenvs, tak je ve __file__ něco jiného, než si myslíš Ty.

Dne čtvrtek 25. února 2021 v 14:59:21 UTC+1 uživatel jakub....@gmail.com napsal:

[MirekZv]

@Honza(jan.be..)

Ahoj. Já jsem django-environ snad trochu používal (už si přesně nepamatuju), ale protože to zatím nedávám nikam do cloudu, ale na virtuální server, tak jsem nakonec ENV proměnné, aspoň prozatím, úplně opustil.

Používám místo toho klasický ini file, někde v /etc/django/myproject.ini, který čtu pomocí RawConfigParser ze standardní knihovny.

Dne pátek 26. února 2021 v 10:28:02 UTC+1 uživatel MirekZv napsal:

[Vladimír Macek]

Mirku, každý jsme nějak začínali a někteří jsme psali dlouhé dotazy s
představou, že svět budou naše problémy zajímat.

Číst tvoje texty je otravné, z větší části proto, že z nich sálá nedostatek
pokory. To se ti tu lidi snažili naznačit.

Pokud budeš ještě svoje výlevy upgradovat ad hominem, dospěješ k tomu, že
budeš už zcela ignorovaný.

Tohle jsem napsal, abych ti poskytl reflexi, která by ti mohla pomoct.
Prosím tě, neodpovídej na ni.

V.

[MirekZv]

@Vláďa - Proč čteš topics, které Tě nezajímají nebo jsou dokonce otravné?

Víš co, tak toto teda ne. Ačkoli na sobě obvykle nechám dříví štípat, toto si líbit nenechám - toto je příliš, to je přes čáru.

Promiň, ale já jsem dost starej chlap na to, abych už poznal, co je myšleno dobře a co není. Jakkoli to přetéká medovými slovy.

Tedy, možná to v rámci dvorečku své mysli dobře myslíš. Ale zamysli se, co Ti dává právo se ke mně takto chovat?

A jestli jsi rovný člověk, tak se neurazíš a není důvod nebýt nadále přáteli.

Možná jsi neuvážil, že s některými lidmi v diskuzi se známe, takže si můžeme dovolit občas nějakou ironickou poznámku (ke mně i ode mě).

Můj názor:

- Koho téma nezajímá, ten ho nečte,

- Věcné příspěvky o problémech v Pythonu a Djangu,

- Eliminovat hraběcí rady, typické zlo českých e-diskuzí,

- Oživit českou diskuzi: Víc věcných příspěvků než vloni (2 měsíčně?)

Dne pátek 26. února 2021 v 10:35:03 UTC+1 uživatel Vláďa Macek napsal: