Skip to content
This repository has been archived by the owner on Jan 25, 2022. It is now read-only.

Django versions out-of-date #965

Open
rwillmer opened this issue Jul 7, 2020 · 4 comments
Open

Django versions out-of-date #965

rwillmer opened this issue Jul 7, 2020 · 4 comments

Comments

@rwillmer
Copy link

rwillmer commented Jul 7, 2020

  • 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
Copy link
Collaborator

Hey, @rwillmer, thanks for reporting this!

@jonathan-s
Copy link
Collaborator

jonathan-s commented Jul 15, 2020

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
Copy link

bittner commented Oct 1, 2020

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
Copy link
Collaborator

@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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants