Adds a application as example

[cuducos]

Given @jhrdt great contribution on #20, I could add an example application with Django's native admin running in parallel with this Django Public Admin:

• Here are what I suggested to the docs
• And the files are in the example/ directory

[jhrdt]

Hej,

I am just curious, but adding manage.py at the top level of the repository and including a complete django project, interferes with the app character/layout of the repository/project.

I wouldn't expect to see a demo django project in a repository for a django app.

Looking at the layout of other app projects like DRF or nested_admin, makes me believe that this change makes things more complicated.

There are other possibilities, like a second repository (that includes the example project) with a git submodule that contains django-public-admin. Or a dedicated branch for development. A docker container that contains a developtment environment might also be an option.

There might also be the problem, that the example django project need to be up to date with django's latests releases. This might also include to adapt to new django project layouts/conventions that might come over time (e.g. changes in settings.py and other stuff). This might double the work.

[cuducos]

I hear you, @jhrdt.

In my opinion, we need to differentiate what is a Python package and what is a repository. I am adding things to a respository, not to the Python package — neither the example/ directory nor the manage.py is copied to site-packages.

```console (tempenv-25aa264095cf2) $ pip install git+https://github.com/cuducos/django-public-admin.git#v4 Collecting git+https://github.com/cuducos/django-public-admin.git#v4 Cloning https://github.com/cuducos/django-public-admin.git to /tmp/pip-req-build-3f7j6jht Installing build dependencies ... done Getting requirements to build wheel ... done Preparing wheel metadata ... done Collecting django>=2 Downloading Django-3.1.2-py3-none-any.whl (7.8 MB) |████████████████████████████████| 7.8 MB 2.4 MB/s Collecting pytz Using cached pytz-2020.1-py2.py3-none-any.whl (510 kB) Collecting sqlparse>=0.2.2 Downloading sqlparse-0.4.1-py3-none-any.whl (42 kB) |████████████████████████████████| 42 kB 1.4 MB/s Collecting asgiref~=3.2.10 Using cached asgiref-3.2.10-py3-none-any.whl (19 kB) Building wheels for collected packages: django-public-admin Building wheel for django-public-admin (PEP 517) ... done Created wheel for django-public-admin: filename=django_public_admin-0.0.3-py3-none-any.whl size=5350 sha256=107c3d309fa4d1447b17aad8d09cae3d8c880a41d2a7e382a45441f89b41b89c Stored in directory: /tmp/pip-ephem-wheel-cache-4jp9yx6r/wheels/12/df/ff/e2dd49080d61059ec977b22a684b464bb5db0a93211d47be5c Successfully built django-public-admin Installing collected packages: pytz, sqlparse, asgiref, django, django-public-admin Successfully installed asgiref-3.2.10 django-3.1.2 django-public-admin-0.0.3 pytz-2020.1 sqlparse-0.4.1 (tempenv-25aa264095cf2) $ pwd /home/cuducos/.virtualenvs/tempenv-25aa264095cf2/lib/python3.8/site-packages/public_admin (tempenv-25aa264095cf2) $ ls -laGh total 24K drwxr-xr-x 4 cuducos 4.0K Oct 8 14:49 ./ drwxr-xr-x 21 cuducos 4.0K Oct 8 14:49 ../ -rw-r--r-- 1 cuducos 1.1K Oct 8 14:49 admin.py -rw-r--r-- 1 cuducos 0 Oct 8 14:49 __init__.py drwxr-xr-x 2 cuducos 4.0K Oct 8 14:49 __pycache__/ -rw-r--r-- 1 cuducos 3.4K Oct 8 14:49 sites.py drwxr-xr-x 3 cuducos 4.0K Oct 8 14:49 templates/ (tempenv-25aa264095cf2) $ cd .. (tempenv-25aa264095cf2) $ ls -laGh drwxr-xr-x 21 cuducos 4.0K Oct 8 14:49 ./ drwxr-xr-x 3 cuducos 4.0K Oct 8 14:48 ../ drwxr-xr-x 3 cuducos 4.0K Oct 8 14:49 asgiref/ drwxr-xr-x 2 cuducos 4.0K Oct 8 14:49 asgiref-3.2.10.dist-info/ drwxr-xr-x 2 cuducos 4.0K Oct 8 14:48 _distutils_hack/ -rw-r--r-- 1 cuducos 152 Oct 8 14:48 distutils-precedence.pth drwxr-xr-x 19 cuducos 4.0K Oct 8 14:49 django/ drwxr-xr-x 2 cuducos 4.0K Oct 8 14:49 Django-3.1.2.dist-info/ drwxr-xr-x 2 cuducos 4.0K Oct 8 14:49 django_public_admin-0.0.3.dist-info/ -rw-r--r-- 1 cuducos 126 Oct 8 14:48 easy_install.py drwxr-xr-x 5 cuducos 4.0K Oct 8 14:49 pip/ drwxr-xr-x 2 cuducos 4.0K Oct 8 14:48 pip-20.2.3.dist-info/ -rw-r--r-- 1 cuducos 0 Oct 8 14:48 pip-20.2.3.virtualenv drwxr-xr-x 4 cuducos 4.0K Oct 8 14:48 pkg_resources/ drwxr-xr-x 4 cuducos 4.0K Oct 8 14:49 public_admin/ drwxr-xr-x 2 cuducos 4.0K Oct 8 14:49 __pycache__/ drwxr-xr-x 4 cuducos 4.0K Oct 8 14:49 pytz/ drwxr-xr-x 2 cuducos 4.0K Oct 8 14:49 pytz-2020.1.dist-info/ drwxr-xr-x 6 cuducos 4.0K Oct 8 14:48 setuptools/ drwxr-xr-x 2 cuducos 4.0K Oct 8 14:48 setuptools-50.3.0.dist-info/ -rw-r--r-- 1 cuducos 0 Oct 8 14:48 setuptools-50.3.0.virtualenv drwxr-xr-x 5 cuducos 4.0K Oct 8 14:49 sqlparse/ drwxr-xr-x 2 cuducos 4.0K Oct 8 14:49 sqlparse-0.4.1.dist-info/ -rw-r--r-- 1 cuducos 18 Oct 8 14:48 _virtualenv.pth -rw-r--r-- 1 cuducos 5.6K Oct 8 14:48 _virtualenv.py drwxr-xr-x 4 cuducos 4.0K Oct 8 14:48 wheel/ drwxr-xr-x 2 cuducos 4.0K Oct 8 14:48 wheel-0.35.1.dist-info/ -rw-r--r-- 1 cuducos 0 Oct 8 14:48 wheel-0.35.1.virtualenv ```

So I would agree with basically all your sentences if you were addressing a Python package, but I cannot agree on the same statements for a single repository.

I am just curious, but adding manage.py at the top level of the repository and including a complete django project, interferes with the app character/layout of the repository/project.

It was zero influence over the project as a Python package, for sure. And it has an arguably positive influence on the repository since now future users have an working example of the package available here.

I wouldn't expect to see a demo django project in a repository for a django app.

I think this is pretty nice. I like it that, for example, django-multiselectfield and django-tables2 have working examples — although they moved the manage.py and the application interely to a example/ folder. Othe packages form the Flask world also have working examples, such as Flasgger, Dynaconf, both with +1k starts on GitHub… so I just can't see why not.

Looking at the layout of other app projects like DRF or nested_admin, makes me believe that this change makes things more complicated.

And surely we can be selective to find examples to whatever we are claiming : )

There are other possibilities, like a second repository (that includes the example project) with a git submodule that contains django-public-admin. Or a dedicated branch for development. A docker container that contains a developtment environment might also be an option.

I think all of that would make sense if the work on the main branch of this repo was intense — which is not the case. We have 5 contributors and 33 starts at the moment. And only 29 commitis on the main branch. We're in alpha. Git submodules, adding dependency on Docker, or changing branches just to have an working example seam all good solutions… but an overkill at this time. I prefer to keep it simple.

There might also be the problem, that the example django project need to be up to date with django's latests releases. There might also be the problem, that the example django project need to be up to date with django's latests releases.

This is not a problem, actually. At least, not a problem added by this PR. If new Django versions breaks anything, carrying about the versioning at pyproject.toml and all the consequences is a problem that we already have.

Firthermore, I haven't mentioned the possibility of runing integration tests with this working example, which would be a plus, right?

Anyway… I do agree with the confusion caused by manage.py at the root level, so I might move everything related to the example to the example/ directory.

I udnerstand we might disagree on many points here, but I would love to still have a follow up from you. In sum, I am trying to keep things as simple as possible (at least, while this is still a small project).

[jhrdt]

I hear you, @jhrdt.

In my opinion, we need to differentiate what is a Python package and what is a repository. I am adding things to a respository, not to the Python package — neither the example/ directory nor the manage.py is copied to site-packages.

So I would agree with basically all your sentences if you were addressing a Python package, but I cannot agree on the same statements for a single repository.

I am aware, that the final artifact will only contain application code.

I am just curious, but adding manage.py at the top level of the repository and including a complete django project, interferes with the app character/layout of the repository/project.

It was zero influence over the project as a Python package, for sure. And it has an arguably positive influence on the repository since now future users have an working example of the package available here.

I wouldn't expect to see a demo django project in a repository for a django app.

I think this is pretty nice. I like it that, for example, django-multiselectfield and django-tables2 have working examples — although they moved the manage.py and the application interely to a example/ folder. Othe packages form the Flask world also have working examples, such as Flasgger, Dynaconf, both with +1k starts on GitHub… so I just can't see why not.

Looking at the layout of other app projects like DRF or nested_admin, makes me believe that this change makes things more complicated.

And surely we can be selective to find examples to whatever we are claiming : )

Yes, thats a matter of taste.

There are other possibilities, like a second repository (that includes the example project) with a git submodule that contains django-public-admin. Or a dedicated branch for development. A docker container that contains a developtment environment might also be an option.

I think all of that would make sense if the work on the main branch of this repo was intense — which is not the case. We have 5 contributors and 33 starts at the moment. And only 29 commitis on the main branch. We're in alpha. Git submodules, adding dependency on Docker, or changing branches just to have an working example seam all good solutions… but an overkill at this time. I prefer to keep it simple.

I would agree on that.

There might also be the problem, that the example django project need to be up to date with django's latests releases. There might also be the problem, that the example django project need to be up to date with django's latests releases.

This is not a problem, actually. At least, not a problem added by this PR. If new Django versions breaks anything, carrying about the versioning at pyproject.toml and all the consequences is a problem that we already have.

Right.

Firthermore, I haven't mentioned the possibility of runing integration tests with this working example, which would be a plus, right?

Yes, that is a benefit.

Anyway… I do agree with the confusion caused by manage.py at the root level, so I might move everything related to the example to the example/ directory.

I udnerstand we might disagree on many points here, but I would love to still have a follow up from you. In sum, I am trying to keep things as simple as possible (at least, while this is still a small project).

So at the end, its a matter of taste : ) .

[cuducos]

So at the end, its a matter of taste : )

Maybe it is. But either way I do like to understand your side of the story — and, by doing that, even calling my side into questioning. Many many thanks for contributing to the debate. Probably if this package gets more popular over time, Many of these ideas will be needed!