Added file fields for a release's tarball and checksum

[bmispelon]

This is in preparation for https://code.djangoproject.com/ticket/35980 which will likely change the naming scheme of build files (tarballs and checksums).

Here's a summary of the changes in this PR:

• Added three new (optional) file fields to the Release model: tarball, wheel, and checksum
• Wrote a data migration to populate the file fields based on existing data, so that existing https://www.djangoproject.com/m/releases/...` links keep working (see gist for data/scripts used).
• Add some custom model validation to make the tarball field mandatory when a release is active (ie it has a release date). This is because the template in download.html assumes that all published/active releases have at least a tarball attached to them.
• Added some fieldsets on the release admin form (see screenshot) to make the form a bit neater.
• Added an accept attribute on the admin form file widgets to make it easier to pick the right file for each
• Removed all hardcoded filenames for tarballs and checksums across the site
• Removed custom logic to compute release file names based on date/version number (the actual file names from the Release model can now be used)

Screenshots

I've also prepared a companion PR to the documentation of the release process over at django/django#19178

[nessita]

Overall looks good! Added a comment, but I think it makes sense.

[nessita]

On a second look, and after some local testing, I wonder why we don't spare the new fields and just make them a property? That seems simpler and that it scales better...

[nessita]

@bmispelon Hi! Do you think you'd have any availability to continue your work on this?

[nessita]

@bmispelon Hi! Could you please help me understand whether you'd have availability to keep on this? Otherwise, no worries, I can take it: setuptools is going to be released soon with the fix so we are planning next steps to push this and other changes around it forward. Thank you!

[bmispelon]

@bmispelon Hi! Could you please help me understand whether you'd have availability to keep on this? Otherwise, no worries, I can take it: setuptools is going to be released soon with the fix so we are planning next steps to push this and other changes around it forward. Thank you!

I've picked this up again, thanks for the ping. I've rebased the branch, fixed the CI, and updated the first comment with a list of what's left for me to do.
I'm hoping to be done this week 🤞🏻 (if not, I'll ping you and we can figure out if it makes sense for you to take over)

[bmispelon]

@nessita I think this is ready for a re-review. I've taken your advice and simplified the migration a bit so that only exceptions to the general naming rule are listed explicitly. I've always made a few quality-of-life improvements to the admin form (fieldsets, custom validation) but if you think that's going to get in the way of your work please let me know.

[nessita]

Thank you @bmispelon for this work, I have applied my suggestions locally and I have made other changes based on what we talked during the DSF Office Hours (pushing that now).

I haven't fixed the tests, would you have any availability to fix them? 🌟

[nessita]

I think we should remove this and put it in the model using a FileExtensionValidator. I will add a suggest there.

[bmispelon]

The accept attribute on the <input> also had the benefit of filtering the list of visible files in the file picker, it's not just about validation (which should be done server side, I agree).

[bmispelon]

I've fixed the tests and pushed a few changes:

• Removed the validators: the validation is now all handled in the clean() (I also added a lot more tests)
• Removed the explicit call to full_clean() in save(). This made some unrelated tests fail and is not really needed because the modelforms from the admin will go through that validation: https://github.com/django/django/blob/main/django/forms/models.py#L498

I think we should restore the <input accepts=...> changes for the reasons I wrote in the comment.
Same with the {% if release.checksum %": personally I'd keep it.

Otherwise, I like the changes you made to keep the case of the uploaded artifact, I think it makes sense.

[nessita]

@bmispelon I pushed an update where the ReleaseManager.active method was renamed to .published, taking into consideration the is_active flag. There are no other usages of .active in the code:

$ grep -nR "\.active" --exclude-dir=static_root --exclude-dir=static
blog/models.py:32:        return self.active().filter(pub_date__lte=timezone.now())
djangoproject/scss/_style.scss:377:        &.active {
djangoproject/scss/_style.scss:527:        &.active {
djangoproject/scss/_style.scss:539:        &.active {
djangoproject/scss/_style.scss:577:            &.active a {
djangoproject/scss/_style.scss:1880:    &.active {
djangoproject/scss/_style.scss:1887:            &.active {
djangoproject/scss/_style.scss:1942:        li.active .collapsing-content {
djangoproject/scss/_style.scss:3079:        &.active {

[sarahboyce]

Looks good!

[nessita]

Just a thought, it might be worth changing this in a separate PR/deployment so that we know the data has been migrated successfully

@sarahboyce This is a good idea and I have reverted this change in a separated commit that we can later squash. The rest of the feedback was addressed. Thank you!

[nessita]

This looks great to me!

[bmispelon]

Now we just need a fresh new Django version to test things out. Wanna roll out an unplanned release just for fun? 🙊