I think that's not possible with Django without some quirks. You need to
add apps to your settings.py anyway, so, if these apps are not present
in your repo, it's not working, as there are imports that lead into
nowhere.
Django provides really good support for creating reusable "apps" that
can be used in different Django applications, if correctly done. But you
have to include them hard-coded, it's not possible to create more apps
that "plug" into ONE Django application and extend its functionality
dynamically. And it seems you need that in your case.
So you need either a mono repo, or git submodules that need to be
fetched. I solved a similar problem by building a library that adds such
a plugin support to Django: https://gdaps.readthedocs.io
You can use a Django main application, and install app "plugins" that
add funcationality to your app without touching the settings.py. Just
install the Django/GDAPS app per pip, restart the Django server / manage
migrate, and it should work.
It's not perfect ans still lacks some features, but should solve your
problem.
Yours, Christian
Am 03.04.23 um 16:04 schrieb Piyush Prasad:
Why not use a mono repo?
------------------------------------------------------------------------
*From:* django-developers@googlegroups.com
<django-developers@googlegroups.com> on behalf of Alex Sonar
<alex.son...@gmail.com>
*Sent:* Sunday, April 2, 2023 10:21:33 PM
*To:* Django developers (Contributions to Django itself)
<django-developers@googlegroups.com>
*Subject:* Re: The problem of versioning a large project.
It is about one project that includes many applications.
We would like to separate the repository specifically for front-end
guest groups.
With access to parts like: views_groups, templates, dummy_data,
forms_group, helpers_group, static_blob and media_blob as an example.
Now our application tier and the file structure of the project looks
something like in the picture below.
.
├── apps
. ├── .DS_Store
├── app_alpha
│ ├── .git <<<<<<<<<<<<<<<<<<<<<<<<< git alpha
│ └── alpha
│ ├── __init__.py
│ ├── admin_alpha.py
│ ├── api_connectors
│ ├── apps_alpha.py
│ ├── conf_parser_alpha.py
│ ├── controllers_groups
│ ├── dummy_data_alpha
│ ├── db_router_alpha.py
│ ├── forms_group
│ ├── helpers_group
│ ├── media_blob_alpha
│ ├── metadata
│ ├── migrations
│ ├── models_groups
│ ├── signals_alpha.py
│ ├── static_blob__alpha
│ ├── templates
│ ├── urls_alpha.py
│ └── views_groups
├── app_beta
│ ├── .git <<<<<<<<<<<<<<<<<<<<<<<<< git beta
│ └── beta
│ ├── __init__.py
│ …….
├── app_gamma
│ ├── .git <<<<<<<<<<<<<<<<<<<<<<<<< git gamma
│ └── gamma
│ ├── __init__.py
│ …….
├── app_delta
│ ├── .git <<<<<<<<<<<<<<<<<<<<<<<<< git delta
│ └── delta
│ ├── __init__.py
….. …….
On Saturday, April 1, 2023 at 2:56:33 PM UTC+3 Jason Johns wrote:
>Now we have organized versioning, where our project is divided
into separate GIT repositories which are created for each application.
why? what's the reasoning for this? django already has apps, so
why do you need to make multiple projects for single components?
On Friday, March 31, 2023 at 10:15:06 AM UTC-4 cha...@gmail.com wrote:
Like Aharon, I'm not entirely certain what you mean but this line:
> The task looks like bad practice, where we have to create a
repository within another one.
reminded me of git submodules, which I don't think are
considered bad practice. Is that what you mean?
On Thursday, March 30, 2023 at 5:17:41 AM UTC+9 Alex Sonar wrote:
The problem of versioning a large project.
Hi guys, I really got stuck with the challenge, with the
design of versioning for a large project.
Now we have organized versioning, where our project is
divided into separate GIT repositories which are created
for each application.
The new necessity point is to split some of them for
front-end and back-and developers.
The task looks like bad practice, where we have to create
a repository within another one.
Or redesign the file structures of the application itself,
to meet this requirement.
If someone has a similar challenge or practice and helps
me make the right decision, I will be very grateful.
--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/1c2df2fc-0158-4da1-a686-5f2a69435f43n%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/1c2df2fc-0158-4da1-a686-5f2a69435f43n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/PH0PR15MB5640DD26A7890FC754671486FC929%40PH0PR15MB5640.namprd15.prod.outlook.com
<https://groups.google.com/d/msgid/django-developers/PH0PR15MB5640DD26A7890FC754671486FC929%40PH0PR15MB5640.namprd15.prod.outlook.com?utm_medium=email&utm_source=footer>.
--
Dr. Christian González
https://nerdocs.at
--
You received this message because you are subscribed to the Google Groups "Django
developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/8052beb6-5714-352e-a247-53e7548c5801%40nerdocs.at.
