django packages: convert to python packaging format + add python3 variant

[commodo]

Maintainer: me, @cotequeiroz
Compile tested: openwrt/openwrt@917eeaf x86
Run tested: openwrt/openwrt@917eeaf x86

---

This is the last of the series for django packages.
Not doing any updates now. This will be in a later series.

Signed-off-by: Alexandru Ardelean ardeleanalex@gmail.com

[BKPepe]

@jefferyto gave me some hints for pillow ( #8715 (comment)) and I haven't been able look at it until now. As I don't want to block this PR, I will apply changes from @jefferyto and test it.

[commodo]

@jefferyto gave me some hints for pillow ( #8715 (comment)) and I haven't been able look at it until now. As I don't want to block this PR, I will apply changes from @jefferyto and test it.

oh right;
i forgot about that PR;
well, whatever the case/end-result is fine from my side;
we don't need to hurry or anything; i am fine with doing the conversion separately from the upgrade & tweaks
but if you also want to do the upgrade, that is fine from my side

[cotequeiroz]

I have one suggestion for grouping the django packages under their own submenu:
We can add MENU:=1 to Package/django/Default, and change the main django dependency from +PACKAGE_python-$(PKG_NAME):python-django to python-django. Because of the -src packages, we need to add MDEPENDS:=python[3]-django under each Package/python[3]-$(PKG_NAME) definition.

Note that there's no need to worry about compilation of unnecessary packages, because lang/python/django/compile build dependency will be picked up by either pyhton-django or python3-django. So, we don't need to do that conditional dependency for anything that's included in both lists. Note that python3 and python use different Makefiles (and their Makefiles define many other python[3]- packages), so they do need the conditional, as do any packages included in one variant but not in the other.

The result is this:

< > python-distutils-src...................... Python 2.7 distutils (sources)
{M} python-django....... The web framework for perfectionists with deadlines.  --->
<M> python-dns..................................................... dnspython

And then this in the next screen:

--- python-django....... The web framework for perfectionists with deadlines.
-M-   python-django-appconf.......... Helper class for handling config defaults
< >   python-django-appconf-src (NEW)
-M-   python-django-compressor........ Compress CSS/JS into single cached files
< >   python-django-compressor-src (NEW)
-M-   python-django-constance
-M-   python-django-formtools......... High-level abstractions for Django forms
< >   python-django-formtools-src (NEW)
-M-   python-django-jsonfield...................... JSONField for django models
< >   python-django-jsonfield-src........ JSONField for django models (sources) (NEW)
-M-   python-django-picklefield................ Pickled object field for Django
< >   python-django-picklefield-src.. Pickled object field for Django (sources) (NEW)
-M-   python-django-postoffice
< >   python-django-postoffice-src (NEW)
-M-   python-django-ranged-response......... Add Content-Range: to FileResponse
< >   python-django-ranged-response-src (NEW)
-M-   python-django-restframework.............. Web APIs for Django, made easy.
< >   python-django-restframework-src (NEW)
-M-   python-django-simple-captcha........... Simple Django captcha application
< >   python-django-simple-captcha-src (NEW)
-M-   python-django-statici18n
< >   python-django-statici18n-src (NEW)
-M-   python-django-webpack-loader......... Transparently use webpack in django
< >   python-django-webpack-loader-src (NEW)

There are two side-effects: (1) we lose two characters in the title of each django-* package, because of the indentation; (2) django will have to be selected to build the dependent -src packages (-src packages usually have no dependencies).

I don't intend this to be done here, but since we already have a backlog of PRs with changes to these packages, I might as well describe mine 😄, and see where I can stand in line.

[commodo]

I have one suggestion for grouping the django packages under their own submenu:
We can add MENU:=1 to Package/django/Default, and change the main django dependency from +PACKAGE_python-$(PKG_NAME):python-django to python-django. Because of the -src packages, we need to add MDEPENDS:=python[3]-django under each Package/python[3]-$(PKG_NAME) definition.

Note that there's no need to worry about compilation of unnecessary packages, because lang/python/django/compile build dependency will be picked up by either pyhton-django or python3-django. So, we don't need to do that conditional dependency for anything that's included in both lists. Note that python3 and python use different Makefiles (and their Makefiles define many other python[3]- packages), so they do need the conditional, as do any packages included in one variant but not in the other.

The result is this:

< > python-distutils-src...................... Python 2.7 distutils (sources)
{M} python-django....... The web framework for perfectionists with deadlines.  --->
<M> python-dns..................................................... dnspython

And then this in the next screen:

--- python-django....... The web framework for perfectionists with deadlines.
-M-   python-django-appconf.......... Helper class for handling config defaults
< >   python-django-appconf-src (NEW)
-M-   python-django-compressor........ Compress CSS/JS into single cached files
< >   python-django-compressor-src (NEW)
-M-   python-django-constance
-M-   python-django-formtools......... High-level abstractions for Django forms
< >   python-django-formtools-src (NEW)
-M-   python-django-jsonfield...................... JSONField for django models
< >   python-django-jsonfield-src........ JSONField for django models (sources) (NEW)
-M-   python-django-picklefield................ Pickled object field for Django
< >   python-django-picklefield-src.. Pickled object field for Django (sources) (NEW)
-M-   python-django-postoffice
< >   python-django-postoffice-src (NEW)
-M-   python-django-ranged-response......... Add Content-Range: to FileResponse
< >   python-django-ranged-response-src (NEW)
-M-   python-django-restframework.............. Web APIs for Django, made easy.
< >   python-django-restframework-src (NEW)
-M-   python-django-simple-captcha........... Simple Django captcha application
< >   python-django-simple-captcha-src (NEW)
-M-   python-django-statici18n
< >   python-django-statici18n-src (NEW)
-M-   python-django-webpack-loader......... Transparently use webpack in django
< >   python-django-webpack-loader-src (NEW)

There are two side-effects: (1) we lose two characters in the title of each django-* package, because of the indentation; (2) django will have to be selected to build the dependent -src packages (-src packages usually have no dependencies).

I don't intend this to be done here, but since we already have a backlog of PRs with changes to these packages, I might as well describe mine smile, and see where I can stand in line.

given the amount of duplicated/repetitive code, some grouping makes sense

[commodo]

Changelog v1 -> v2:

• django-statici18n: shortened the title

this was the only thing that seemed to me, that had a clear conclusion/change associated;
if i missed something, feel free to ping me

[commodo]

Changelog v2 -> v3:

• fixed PKG_RELEASE bumps

[BKPepe]

Would you please rebase your PR against master to resolve conflicts, which I did as I merged pillow and qrcode? I will appreciate if you can keep the bump of PKG_RELEASE for qrcode together with change of email address.

[commodo]

sure
thanks for the heads up;
i was busy in some other parts of things and did not notice or forgot that pillow was merged;

[BKPepe]

It's fine as I did it a few minutes ago. :)

[commodo]

oh;
emails propagate in different order then

[commodo]

Changelog v3 -> v4:

• rebased on top of PR pillow: update to version 6.0.0, add Python3 variant #8715
• refreshed commits on new base