Soru Büyük Django uygulama düzeni


Django'ya dayanan, web tabanlı bir üniversite portalı geliştiren bir takımdayım. Hala keşif aşamalarındayız ve proje / geliştirme ortamını ortaya çıkarmanın en iyi yolunu bulmaya çalışıyorum.

İlk düşüncem, sistemi sistemin farklı bölümlerini ayırmak için alt uygulamaları içeren bir Django "uygulaması" olarak geliştirmektir. Bu "alt" uygulamaları yapmamın nedeni, ana uygulama dışında herhangi bir kullanımı olmayacaklarıdır, dolayısıyla bunları ayrı ayrı dağıtmanın çok az anlamı olacaktır. Portalın birden fazla yerde (örneğin farklı üniversitelerde) kurulmasını öngörüyoruz, böylece ana uygulama onu yüklemek için bir dizi Django projesine bırakılabilir. Bu nedenle, her konumun projesi için farklı bir havuzumuz var. settings.py yüklü portal uygulamalarını tanımlayan dosya ve urls.py URL'leri ona yönlendirmek.

Yine de bazı başlangıç ​​kodlarını yazmaya başladım ve bir problemle karşı karşıya geldim. Kullanıcı kimlik doğrulaması ve profillerini işleyen kodlardan bazıları evsiz gibi görünüyor. Portal uygulamasında, portalın işlevselliği ile ilgili olmadığı için kavramsal olarak ait değildir. Bununla birlikte, aynı zamanda, proje havuzuna gidemez - daha sonra her bir konumun deposunun üzerindeki kodu çoğaltıyormuşum gibi. Bu kodda bir hata bulmuş olsaydım, örneğin, düzeltmeyi el ile tüm proje dosyalarının üzerine çoğaltmak zorunda kalırdım.

Düzeltme fikrim, tüm projeyi bir "ana" konum projesinin çatalı haline getirmektir, böylece bu master'dan herhangi bir değişiklik yapabilirim. Bunun berbat olduğunu düşünüyorum, ve bakmak için bir tane daha deponun olduğu anlamına geliyor.

Bu projeye ulaşmak için daha iyi bir yol arıyorum. Bakabileceğim bir çözüm veya benzer bir örnek önerilebilir mi? Sorun bir Django geliştirdiğim gibi görünüyor proje sadece bir Django değil uygulama.


25
2018-04-19 19:02


Menşei


Jack'in cevabında bahsettiğim gibi: Aslında bir Django olanı geliştiriyorum projeve sadece bir Django değil uygulama. Bu nedenle, projemi tek bir depoda düzenlemem gerekiyor ve uygulamanın yüklü olduğu farklı sitelerin site başlığı gibi şeyleri değiştirmek için local_settings.py gibi bir şey kullanmam gerekiyor. - Rob Golding
(biraz geç, ama ...) Çok fazla djangoya özel bir şey kullanmıyorsanız (yönetici, üçüncü taraf uygulamaları, vb.) Flask gibi daha düşük bir seviyeye sadık kalırım. Böylelikle, yaptığınız şeyler üzerinde tam kontrol sahibi olabilirsiniz. Django'yu üzerinde çalıştığım daha büyük bir projeye koydum. Yaptığım her şey, Django yolunda bir şeyler yapmaya çalışırken sorun yaşadıktan sonra tamamen özel olarak yapılmalı. - orokusaki


Cevaplar:


Bunun için en iyi yol, uygulamaları oluşturmak ve daha sonra bunları birbirine yapıştırmak için bir proje oluşturmaktır. Projelerimin çoğu, her birinde bulunan benzer uygulamalara sahip. E-postalar, notlar, eylem hatırlatmaları, kullanıcı kimliği, vb. Tercihlerim şunun gibidir:

  • proje /
    • settings.py
    • urls.py
    • views.py
    • ...
  • apps /
    • e-postalar /
      • urls.py
      • views.py
      • ...
    • notları /
      • urls.py
      • views.py
      • ...
    • ...

uygulamalar:

"Uygulamaların" her biri kendi başına ve bir settings.py, projenin kendisine güvenmez (diğer uygulamalara da güvenebilir). Uygulamalardan biri, kullanıcı kimlik doğrulaması ve yönetimi. Görevlerini gerçekleştirmek için tüm URL'lere sahip apps/auth/urls.py. Tüm şablonları apps/auth/templates/auth/. Tüm işlevselliği kendi kendine yeten bir şeydir, böylece bir şeyi düzeltmem gerektiğinde nereye gideceğimi biliyorum.

proje:

project/ Bu bireysel uygulamaları bir araya getirmek için gereken tüm yapıştırıcıyı nihai projeye dahil eder. Benim durumumda çok kullanıyorum settings.INSTALLED_APPSiçinde project/ Uygulamalardan hangi görünümlerin bana sunulduğunu ayırt etmek için Bu şekilde alırsam apps.notes benim dışımdan INSTALLED_APPS, her şey hala nota olmadan harika çalışıyor.

Bakım:

Bu düzen / metodoloji / planın uzun vadeli olumlu sonuçları vardır. Uygulamalardan herhangi birini, hemen hemen hiç çalışma olmadan yeniden kullanabilirsiniz. Sistemi aşağıdan yukarıya doğru test edip, uygulamaların her birinin, bütünleştirilmeden önce amaçlandığı şekilde çalışmasını sağlayarak, hataları daha hızlı bulmanızı / çözmenizi sağlar. Yeni bir özelliği, uygulamanın mevcut örneklerine kaydırmadan uygulayabilirsiniz. INSTALLED_APPSbunu göremezler).

Eminim, bir projeyi ortaya koymanın daha iyi belgelenmiş yolları vardır ve daha yaygın olarak kullanılan yollar vardır, ama bu benim için şimdiye kadar en iyi çalışanıdır.


31
2018-04-19 19:27



Uygulamaların hala bağımlılıkları olabileceği konusunda uyarıda bulunuldu. Yani, mantıklı olmalılar. Yorumlarınız varsa, bunun django'nun auth uygulamasına bağlılıkları var. Bir bildirim uygulamanız varsa, e-posta uygulamanıza bağlı olabilir. Bütün bu bağımlılıklar iyi belgelenmelidir. - Justin Abrahms
Yeniden kullanılabilen uygulamaların Django'da nasıl çalıştığını anlıyorum, ancak benim sorunum, uygulamaların bu projenin dışında kesinlikle hiçbir şekilde kullanılmamasından kaynaklanıyor. Bu nedenle, farklı konumlar için benzer kodun sürüm sürümlerini ayrı ayrı nasıl saklarım? - Rob Golding
@Justin, haklısın. Bunu çok az yazdım, işaret ettiğin için teşekkürler. @Rob, örnekler arasında hangi işlevsellik değiştiğine bağlıdır. Bir parçanın çekirdek işlevini (yetkilendirme gibi) değiştirmiyorsanız, o zaman bağımsız bir uygulama olabilir ve nasıl uygulandığı, hangi projenin içine çekildiğine bağlı olarak değişebilir. Bu şekilde auth, sadece projenin kendisi için çatallanmaya ihtiyaç duymaz. - Jack M.
@rob git submodules veya svn externals için aradığınız gibi geliyor? - Justin Abrahms
Bunu kabul edilen cevap olarak işaretliyorum, çünkü yaptığım şeyin aslında bir Django olduğunu fark ettim. projeve sadece bir Django değil uygulama. Bu nedenle, proje yapınız güzel bir uyum ve djangoproject.com web sitesininkiyle çok benzer. Teşekkürler! - Rob Golding


Bir göz atmalısınız:

Genellikle bu proje yapısını kullanırım:

  • / djangoproject
    • / apps
      • Ana ana kod
      • / statik # her alt uygulama statiğe hizmet edebilir
      • / app1
      • / statik # her alt uygulama statiğe hizmet edebilir
      • / App2 ...
    • / scripts # manage.py, wsgi, apache.conf, fabfile.py ...
    • / çekirdek kütüphaneleriniz ...
    • settings.py
    • local_settings.py

/ Apps'deki her uygulama, ana urls.py dosyasında otomatik olarak eklenen bir urls.py dosyasına sahiptir. Ve her uygulama bir git submodule (veya svn harici) olabilir

Ayrıca, git kullanarak, farklı parallels dalları üzerinde çalışabilirsiniz (master / dev / customerA / customerB ...) ve güncellemeleri birleştirme.

Gerçek yeniden kullanılabilir yaratmak django ile çok kolay değil.


4
2018-04-19 19:24



Sürüm kontrolü için Mercurial kullanıyorum ve local_settings numarasını da kullanıyorum. Sorum, projelerin nasıl ayrı tutulacağı hakkında daha fazla bilgi verdi, ancak çekirdek kodun merkezi sürüm kontrollü bir kopyasını saklıyordu. - Rob Golding


Ortak işlevselliği ayrı bir modülde ayıklayabilir ve uygulamalarınızın buna bağlı olmasını sağlayabilirsiniz:

  • my_portal
  • auth_module
  • profiles_module
  • application1 (auth_module'ye bağlı)
  • application2 (auth_module ve profiles_module'ye bağlı)

Bir 'klasik' Django projesinin, kullandığı uygulamaları 'içerdiğini' belirttiği gerçeğinin, resmi görmenizi engellediğini düşünüyorum - aslında, bu gerekli değil. Takılabilir modüller içeren bir proje için, uygulamaları yumurta olarak organize etmenizi ve her şeyi yönetmek için zc.buildout + djangorecipe kullanmayı öneririm.

Bu şekilde modüllerinizi düz tek seviyeli bir yapıda tutabileceksiniz. Yumurta bağımlılıkları belirleme yeteneğine sahiptir, bu yüzden eğer uygulama1'i yüklerseniz (yukarıya bakın), auth_module otomatik olarak yüklenir.

Ayrıca farklı sunuculara dağıtılmış farklı konfigürasyonlara sahip olmak da kolay olacaktır. Farz edelim, uygulama1 yüklü olan server1 ve hem application1 hem de application2 yüklü olan server2 var - sadece iki tane konfigürasyonunuz olabilir:

server1.cfg:

[buildout]
extends = base_deployment.cfg
eggs += application1

server2.cfg:

[buildout]
extends = base_seployment.cfg
eggs += application1
        application2

djangorecipe ayrıca her buildout yapılandırması için farklı ayar dosyaları belirtmenize izin verir, böylece ana bitlerin URL'lerine ve yüklü uygulama ayarlarına gerekli bitleri ekleyebileceksiniz.

Ayrıca, geliştirme yapılandırması için ayrı bir yapılandırma da olabilir (örneğin, debug = True ve Django Debug Toolbar yüklü).


4
2018-04-20 00:20



Buildout hakkında bir şey bilmiyordum, bu yüzden bunu söylediğin için teşekkürler. Yine de bunu yapmanın en iyi yolunu bulduğumdan emin değilim - projemin farklı "permütasyonları" ile özellikle ilgilenmiyorum, genellikle her yerde aynı olacak. Örneğin, başlığı değiştirebilmem ve gerektiğinde şablonları geçersiz kılmam gerek. - Rob Golding
Bu sadece "permutasyonlar" ile ilgili değildir: - djangorecipe, hangi ayar dosyasını kullanacağınızı belirlemenize izin verir, böylece her kurulumun başına, güzel, temiz ve sürüm kontrollü bir şekilde (örn. Settings_production.py diyor ki) ayarları import *; DEBUG = False "ve settings_dev.py" setting import *; DEBUG = True "yazıyor - buildout, üçüncü tarafların (ve kendi) modüllerin hangi sürümlerinin kurulduğunu kontrol etmenize olanak tanıyor; böylelikle kurulumları tekrar tekrar oluşturabilirsiniz. sistem python dizinlerini kirletmeden (virtualenv'e benzer ama daha güzel) her şeyi yerel olarak yükler. - Sergey