Parse Django version from requirements.txt

[johnnymetz]

Description

Request

It would be awesome if this package could parse the Django version from requirements.txt so I don't need to remember to bump the version every time I upgrade the package in requirements.txt. Example code:

with open("requirements.txt") as f:
    for line in f:
        requirement = line.rstrip()
        package, version = requirement.split("==")
        if package.lower() == "django":
            print(version)
# 4.1.7

Another option is to use the current version of Django installed, although this doesn't seem fool-proof (in case someone hasn't updating their requirements in a while):

import django
print(django.__version__)
# 4.1.7

CLI design notes

Per the docs:

The --target-version flag defaults to 2.2

So we may not want to change that default for backward compatibility reasons. Perhaps this could live under a separate flag --parse-version-from-requirements or something like.

Notes

I'm happy to work on this if you think this is doable and worthwhile.

[adamchainz]

It would be awesome if this package could parse the Django version from requirements.txt so I don't need to remember to bump the version every time I upgrade the package in requirements.txt. Example code:

I like the idea but we’d need slightly more robust parsing code.

Also some tools use other sources like pyproject.toml. I think it would be best to support those in one.

Another option is to use the current version of Django installed, although this doesn't seem fool-proof (in case someone hasn't updating their requirements in a while):

This isn't compatible with pre-commit, which runs tools in isolated environments. So it could help some users, but I feel a majority use pre-commit.

So we may not want to change that default for backward compatibility reasons. Perhaps this could live under a separate flag --parse-version-from-requirements or something like.

Perhaps we could repurpose --target-version to take the filename to parse, if it's not of the form <digits>.<digits>?

[johnnymetz]

Perhaps we could repurpose --target-version to take the filename to parse, if it's not of the form .?

Awesome idea. Keeps it simple.

[adamchainz]

On second thoughts, a mutally exclusive argument like --target-version-from is probably better, actually. It will be clearer what's happening.

Would you like to work on this @johnnymetz , at least for .txt file support?

[johnnymetz]

On second thoughts, a mutually exclusive argument like --target-version-from is probably better

I agree. Great idea.

Would you like to work on this

I'd love to work on this if that's okay, unless you really want to implement then happy to pass to off.

[adamchainz]

Yes please try it!

[adamchainz]

Rather than requirements.txt, I think we should consider pyproject.toml as a source of truth, perhaps the only one. Black infers its target version from pyproject.toml. dependencies there have a standardized format that work whatever the tool, so hopefully this would be one-and-done.

[gav-fyi]

I was going to take a look at implementing this change, but was wondering which setting to use as the source?

Black uses [project.requires-python] and [tool.black.target_version].

Do you envision a new setting for [tool.django-upgrade.target-version] to be used, or were you thinking of parsing the [project.dependencies] for a Django version?

[adamchainz]

Let's parse [project.dependencies] only, for the first pass.

[gav-fyi]

Thanks.

The python packaging library handles a lot of the version pinning/parsing edge-cases, but is an extra requirement to the library. Would you be opposed to using it for this use case?