Django versions out-of-date

[rwillmer]

• Date you used Cookiecutter DjangoPackage: 7 Jul 2020

• Cookiecutter version used, if known: 1.7.2

• Python version: 3.7

• Operating System: OSX

Description

Describe what you were trying to get done. Tell us what happened, what went wrong, and what you expected to happen.

What I Did

I created a new djangopackage using this cookiecutter.

It only allows out-of-date versions of Django to be specified.

...
django_versions [1.11,2.1]: 3.0
...
ERROR:pre_gen_project:Invalid Django version "3.0". 
ERROR: Stopping generation because pre_gen_project hook script didn't exit successfully
Hook script failed (exit status: 1)

The current versions for Django are 3.0 and 2.2

[jonathan-s]

Hey, @rwillmer, thanks for reporting this!

[jonathan-s]

I'm sure that you've (@rwillmer) either worked past this or ended up not using this cookiecutter. For anyone else who stumbles upon this issue in the meantime I'd suggest to clone this repo and remove the following lines -> https://github.com/pydanny/cookiecutter-djangopackage/blob/master/hooks/pre_gen_project.py#L17-L22

The caveat here is that when you generate the cookiecutter, it won't generate the correct versions in setup.py and tox.ini.

There is a proper fix for this in the works in detailed in #966, but it requires an upstream change which I'm waiting for.

[bittner]

Why don't we approach this more pragmatically? I see a simple and a more elaborate approach:

1. The ALLOWED_VERSIONS could simply be a list of old (obsolete), current (valid) and future (possibly not yet available) version numbers. It's just about a plausibility check, isn't it? This could be based on Django's version history and future and we would only focus on removing the non-LTS versions from time to time (if at all), e.g.

   ALLOWED_VERSIONS = [
      '1.9', '1.10', '1.11',
      '2.0', '2.1', '2.2',
      '3.0', '3.1', '3.2',
      '4.0', '4.1', '4.2',
   ]

2. Alternatively, we would use PyPI to dynamically find out which (modern) versions are actually available, e.g. by implementing something like follows in pure Python:

   $ curl -s https://pypi.org/simple/django/ \
      | grep 'Django-[23]\.[0-9]\.[0-9]\.tar' \
      | sed -E 's/^.*(Django-.*).*Django-(.*)\.[0-9]\.tar.*$/\2/' \
      | uniq
   2.0
   2.1
   2.2
   3.0
   3.1

The former approach is easily done and reduces the maintenance effort to near zero. The latter is certainly more accurate, but also potentially prone to errors (e.g. lost connectivity, API changes, etc.).

[jonathan-s]

@bittner You are right, fixing the ALLOWED_VERSIONS would make things usable. However fixing that is just a surface level fix. The ideal would be for this to be tied into tox.ini, travis.yml and so on.