internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: djangopackages/djangopackages

Issue:
🐛  License shows "UNKNOWN" 
The license field shows "UNKNOWN" if the pypi "license" field is blank, even if contains a valid License in the classifiers fields. 


Discussion:

Resolving patch:
diff --git a/package/models.py b/package/models.py
--- a/package/models.py
+++ b/package/models.py
@@ -267,8 +267,8 @@ def fetch_pypi_data(self, *args, **kwargs):
                 ):
                     self.supports_python3 = True
 
-            # add to versions
-            if "license" in info and info["license"]:
+            # do we have a license set?
+            if "license" in info and len(info["license"]):
                 licenses = [info["license"]]
                 for index, license in enumerate(licenses):
                     if license or "UNKNOWN" == license.upper():
@@ -280,6 +280,16 @@ def fetch_pypi_data(self, *args, **kwargs):
                 version.licenses = licenses
                 version.license = licenses[0]
 
+            # do we have a license set in our classifier?
+            elif "classifiers" in info and len(info["classifiers"]):
+                licenses = []
+                for classifier in info["classifiers"]:
+                    if classifier.startswith("License"):
+                        licenses.append(classifier.split("::")[-1].strip())
+
+                version.licenses = licenses
+                version.license = licenses[0]
+
             # version stuff
             try:
                 url_data = release["urls"][0]


Test patch:
Repository: djangopackages/djangopackages

Issue:
🔍  Detect Archived GitHub Projects
Semi-related to #681

When we use the GitHub API to check the stats on projects, we should look for the archived bit so that we can flag packages. This could be an archived_date field, or maybe there's a good way  to flag these packages for review with a note? 

See https://github.com/berinhard/model_mommy for an example. 


Discussion:
Hi @jefftriplett ! I intend to work on this issue and will be submitting a PR soon :+1:  
Sounds great. 👍 
@jefftriplett and @cacoze it looks like this was fixed with PR #761. Is that correct? 
@ryancheley The feature was added, but I noticed a few packages like https://djangopackages.org/packages/p/dj-paginator/ are not being flagged. I'm going to poke around and see if we missed something obvious. 

Resolving patch:
diff --git a/package/admin.py b/package/admin.py
--- a/package/admin.py
+++ b/package/admin.py
@@ -41,6 +41,7 @@ class PackageAdmin(VersionAdmin):
                     "score",
                     "created_by",
                     "last_modified_by",
+                    "date_repo_archived",
                     "date_deprecated",
                     "deprecates_package",
                     "deprecated_by",
@@ -55,7 +56,6 @@ class PackageAdmin(VersionAdmin):
                     "repo_description",
                     "repo_watchers",
                     "repo_forks",
-                    "date_repo_archived",
                     "commit_list",
                     "pypi_downloads",
                     "pypi_classifiers",
diff --git a/package/management/commands/package_updater.py b/package/management/commands/package_updater.py
--- a/package/management/commands/package_updater.py
+++ b/package/management/commands/package_updater.py
@@ -41,7 +41,7 @@ def handle(self, *args, **options):
 
             try:
                 try:
-                    package.fetch_metadata(fetch_pypi=False)
+                    package.fetch_metadata(fetch_pypi=False, fetch_repo=True)
                     package.fetch_commits()
                 except Exception as e:
                     logger.error(
diff --git a/package/repos/github.py b/package/repos/github.py
--- a/package/repos/github.py
+++ b/package/repos/github.py
@@ -43,14 +43,12 @@ def fetch_metadata(self, package):
         if repo is None:
             return package
 
-        # import pytest
-        # pytest.set_trace()
-
         # package.repo_watchers = repo.watchers
         package.repo_watchers = repo.watchers_count
 
         if repo.archived:
-            package.date_repo_archived = timezone.now()
+            if not package.date_repo_archived:
+                package.date_repo_archived = timezone.now()
 
         # package.repo_forks = repo.forks
         package.repo_forks = repo.forks_count


Test patch:
Repository: djangopackages/djangopackages

Issue:
Modernise tables / dj-pagination is archived
I was looking at some of the other dependencies of the project and noticed that dj-pagination had been [archived](https://github.com/pydanny/dj-pagination).

I'm assuming the project would therefore like to try and remove reliance on this package?

The package is used in a couple of [templates](https://github.com/djangopackages/djangopackages/blob/506184070e37bdcfad5658d8a1579f03db2593aa/templates/package/category.html#L54). I have had a look at what it would take to move to Django's own `Paginator` and this looks simple enough. However it is used in conjunction with `webstack-django-sorting` (wds) which enables you to click on the table headers to sort the data.

Unfortunately the package [doesn't work](https://github.com/webstack/webstack-django-sorting/issues/12) with Django's Paginator. So the complexity here is much higher than "just" a Paginator.

So I guess there are few options:

- Leave things alone until there is an incompatibility with Django (I've had a PR merged to wds to add Django 4.0 support)

- Use Django Paginator, drop the sort feature

- use Django Paginator, roll our own sort feature

- Use another package, `django-tables2` seems to do what we need, it looks like it covers the features of both of the above packages and seems to be well maintained (release on PyPI already declares django 4.0 and py 3.10 support)

https://github.com/jieter/django-tables2

What are your thoughts, there are certainly things I am missing, but to me it feels like Django-tables2 is the front runner here. Not sure what a patch to include it would actually look like though but feels like it is worth investigating. 


On mobile apologies for poor spelling/ grammar etc


Discussion:
Great catch. I'd either lean towards Django's built-in or `django-tables2` if it gives some compelling features. 

My main goal this quarter is a pretty big grid refactor and to address some performance issues. 
Not everything is covered yet, but I made a dent into it with #815 

Resolving patch:
diff --git a/settings/base.py b/settings/base.py
--- a/settings/base.py
+++ b/settings/base.py
@@ -80,7 +80,6 @@
     "django.contrib.auth.middleware.AuthenticationMiddleware",
     "django.contrib.messages.middleware.MessageMiddleware",
     "django.middleware.clickjacking.XFrameOptionsMiddleware",
-    "dj_pagination.middleware.PaginationMiddleware",
     "waffle.middleware.WaffleMiddleware",
     "django_structlog.middlewares.RequestMiddleware",
     "maintenance_mode.middleware.MaintenanceModeMiddleware",
@@ -155,7 +154,6 @@
     # external
     "maintenance_mode",
     "crispy_forms",
-    "dj_pagination",
     "django_better_admin_arrayfield",
     "django_extensions",
     "django_tables2",


Test patch:
Repository: djangopackages/djangopackages

Issue:
Packages with custom git repos are not being scored
See this tweet: https://twitter.com/morenoh149/status/1580971411145125888

Package scoring should factor in packages that exist on PyPI, but might have a custom repo location. They appear to be scored as a 0 and won't show up in Grids. 


Discussion:
I took a quick peek at this. It seems like the `Package.calculate_score()` method returns `0` if the `Package.repo_watchers` field is set to `0`.
https://github.com/djangopackages/djangopackages/blob/9951ae1f3ceff06e37af1e2c413dfc1e5552317d/package/models.py#L394-L416

And the `grid_detail` view is filtering out the packages that score `<1`. (This makes the package not show up in the grid)
https://github.com/djangopackages/djangopackages/blob/9951ae1f3ceff06e37af1e2c413dfc1e5552317d/grid/views.py#L306-L308

This happens when the `UnsupportedHandler` (Unsupported Git Service) is used.

https://github.com/djangopackages/djangopackages/blob/9951ae1f3ceff06e37af1e2c413dfc1e5552317d/package/repos/unsupported.py#L11

A quick fix would be to either update the `Package.calculate_score()` method to use the value `1` for `repo_watchers` if `Package.repo_watchers` field is set to `0` or set a default for `Package.repo_watchers` in the `UnsupportedHandler`

Resolving patch:
diff --git a/grid/views.py b/grid/views.py
--- a/grid/views.py
+++ b/grid/views.py
@@ -304,7 +304,7 @@ def grid_detail(request, slug, template_name="grid/grid_detail.html"):
     }
 
     grid_packages = grid.grid_packages.select_related("package").filter(
-        package__score__gt=max(0, settings.PACKAGE_SCORE_MIN)
+        package__score__gte=max(0, settings.PACKAGE_SCORE_MIN)
     )
 
     if filters.get("python3"):


Test patch:
diff --git a/package/tests/test_repos.py b/package/tests/test_repos.py
--- a/package/tests/test_repos.py
+++ b/package/tests/test_repos.py
@@ -151,7 +151,8 @@ def test_base_handler_get_repo_for_repo_url():
 sebpiq/spiteat/
 schinckel/django-timedelta-field/
 http://projects.unbit.it/hg/uwsgi
-http://www.dataportal.it"""
+http://www.dataportal.it
+https://hg.code.netlandish.com/~petersanchez/django-impersonate"""
     for sample in samples.split("\n"):
         assert isinstance(get_repo_for_repo_url(sample), UnsupportedHandler)
Repository: djangopackages/djangopackages

Issue:
Invalidate Cloudflare cache when a static file changes
**Describe the bug**

On the #719 the [grid css](https://github.com/djangopackages/djangopackages/blob/930c7565ea216e42380694d32f1311b6d64e78b9/static/css/grid.css) was improved, but in production the old version is still served. 

I'm not sure if something is wrong with [`collectstatic`](https://github.com/djangopackages/djangopackages/blob/930c7565ea216e42380694d32f1311b6d64e78b9/compose/django/start.sh#L3), with some Caddy HTTP headers or a configuration on Cloudflare

**To Reproduce**
Steps to reproduce the behavior:
1. Open the https://djangopackages.org/static/css/grid.css and check if it contains the [new css ](https://github.com/djangopackages/djangopackages/blob/930c7565ea216e42380694d32f1311b6d64e78b9/static/css/grid.css)

**Expected behavior**

Whenever a new deployment occurs, if a static file has changed, Cloudflare must invalidate the previous version and serve the new version.

**Desktop (please complete the following information):**
 - OS: Ubuntu 20.04
 - Browser: Google Chrome v95.0.4638.54





Discussion:
I found out I don't have access to the Cloudflare account
Should be doable with https://developers.cloudflare.com/cache/how-to/purge-cache

I transferred Cloudflare into my personal account, but I'll poke around to see if there's a team option or if we need to create a new account, etc. 

Resolving patch:
diff --git a/fabfile.py b/fabfile.py
--- a/fabfile.py
+++ b/fabfile.py
@@ -152,6 +152,10 @@ def maintenance_mode_off(service):
     docker_compose(f"exec {service} python manage.py maintenance_mode off")
 
 
+def purge_cache(service):
+    docker_compose(f"exec {service} cli4 --delete purge_everything=true /zones/:djangopackages.org/purge_cache")
+
+
 def docker_compose(command):
     """
     Run a docker-compose command


Test patch:
Repository: djangopackages/djangopackages

Issue:
:closed_lock_with_key: Auth Improvement
**Is your feature request related to a problem? Please describe.**
No.

**Describe the solution you'd like**
A better way to auth in order to use Django packages

**Describe alternatives you've considered**
N/A

**Additional context**
![Screen Shot 2023-02-02 at 1 45 41 PM](https://user-images.githubusercontent.com/20408533/216442020-f0d37ef2-b6fa-421a-af35-8ed4c9e59f2a.png)




Discussion:
@daheats thanks. It's been a while since I logged out/back in. I'll look into what we need to match the names up with the org. 
I think we need to transfer ownership of the OAuth App from personal account to the GitHub Organisation.
Ref: https://docs.github.com/en/apps/oauth-apps/maintaining-oauth-apps/transferring-ownership-of-an-oauth-app

Resolving patch:
diff --git a/settings/base.py b/settings/base.py
--- a/settings/base.py
+++ b/settings/base.py
@@ -256,11 +256,12 @@
 GITHUB_APP_ID = env("GITHUB_APP_ID", default="")
 GITHUB_TOKEN = env("GITHUB_TOKEN", default="")
 
-SOCIAL_AUTH_GITHUB_KEY = GITHUB_APP_ID
-SOCIAL_AUTH_GITHUB_SECRET = GITHUB_API_SECRET
-SOCIAL_AUTH_ENABLED_BACKENDS = ("github",)
-SOCIAL_AUTH_COMPLETE_URL_NAME = "socialauth_complete"
+# GitHub OAuth for login settings
 SOCIAL_AUTH_ASSOCIATE_URL_NAME = "associate_complete"
+SOCIAL_AUTH_COMPLETE_URL_NAME = "socialauth_complete"
+SOCIAL_AUTH_ENABLED_BACKENDS = ("github",)
+SOCIAL_AUTH_GITHUB_KEY = env("SOCIAL_AUTH_GITHUB_KEY", default=GITHUB_APP_ID)
+SOCIAL_AUTH_GITHUB_SECRET = env("SOCIAL_AUTH_GITHUB_SECRET", default=GITHUB_API_SECRET)
 
 
 def SOCIAL_AUTH_DEFAULT_USERNAME(u):


Test patch:
Repository: djangopackages/djangopackages

Issue:
🐛 package_updater is missing the `all` argument
**Describe the bug**

The `package_updater` management command is missing the `all` argument. This means we should at least be testing that we can invoke `--help` on this command too. 

**To Reproduce**
```
root@web2:~# /usr/bin/docker compose -f /code/djangopackages/docker-compose.prod.yml run --rm django-a python manage.py package_updater
[+] Running 1/0
 ⠿ Container djangopackages-redis-1  Running                                                                                                           0.0s
Postgres is up - continuing...
Traceback (most recent call last):
  File "/app/manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", line 446, in execute_from_command_line
    utility.execute()
  File "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", line 440, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/local/lib/python3.9/site-packages/djclick/adapter.py", line 68, in run_from_argv
    exit_code = self.main(
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1055, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.9/site-packages/djclick/adapter.py", line 50, in invoke
    return super(DjangoCommandMixin, self).invoke(ctx)
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 760, in invoke
    return __callback(*args, **kwargs)
TypeError: command() missing 1 required positional argument: 'all'
```



Discussion:

Resolving patch:
diff --git a/package/management/commands/package_updater.py b/package/management/commands/package_updater.py
--- a/package/management/commands/package_updater.py
+++ b/package/management/commands/package_updater.py
@@ -24,7 +24,7 @@ def __init__(self, error, title):
 
 @click.command()
 @click.option("--limit", default=None, type=int)
-def command(all, limit):
+def command(limit):
     """Updates all the GitHub Packages in the database."""
 
     github = github_login(token=settings.GITHUB_TOKEN)


Test patch:
diff --git a/package/tests/test_package_updater.py b/package/tests/test_package_updater.py
new file mode 100644
--- /dev/null
+++ b/package/tests/test_package_updater.py
@@ -0,0 +1,9 @@
+import pytest
+
+from click import exceptions
+from django.core.management import call_command
+
+
+def test_package_updater_command(db):
+    with pytest.raises(exceptions.Exit):
+        call_command("package_updater", "--help")
Repository: djangopackages/djangopackages

Issue:
all /grids/ views are broken
**Describe the bug**
Clicking on any of the grid listings at the top, for example [deployment](https://djangopackages.org/grids/g/deployment/) generates an error

**To Reproduce**
Steps to reproduce the behavior:
1. Go to Home Page
2. Click on `Deployment` (or any package listed at the top)
3. See error

**Expected behavior**
Clicking on deployment will list out the packages that are deployment related

**Screenshots**

<img width="1366" alt="image" src="https://github.com/djangopackages/djangopackages/assets/9857779/b70399ca-4d19-4f61-b645-afaa70fc840e">




Discussion:
also getting this issue
me too 😢😭 but thx for your job 
+1
also getting this issue

Resolving patch:
diff --git a/settings/base.py b/settings/base.py
--- a/settings/base.py
+++ b/settings/base.py
@@ -154,6 +154,7 @@
     # external
     "maintenance_mode",
     "crispy_forms",
+    "crispy_bootstrap3",
     "django_better_admin_arrayfield",
     "django_extensions",
     "django_htmx",
@@ -334,6 +335,7 @@ def SOCIAL_AUTH_DEFAULT_USERNAME(u):
 ########### end redis setup
 
 ########### crispy_forms setup
+CRISPY_ALLOWED_TEMPLATE_PACKS = "bootstrap3"
 CRISPY_TEMPLATE_PACK = "bootstrap3"
 ########### end crispy_forms setup
 


Test patch:
Repository: djangopackages/djangopackages

Issue:
Use Official PostgreSQL Docker Image for "postgres" Docker Service
I'd like to remove the `postgres/Dockerfile` at some too since that feels like part of a different era and I don't see where that's useful anymore. 

_Originally posted by @jefftriplett in https://github.com/djangopackages/djangopackages/pull/1076#discussion_r1421759886_


Discussion:
I'm 3 to 6 months of using the `pgautoupgrade/pgautoupgrade:latest` for a dozen+ projects and I'm a fan. The project/image is designed to make postgres upgrades painless and so far so good for me. 

I'm also happy to adopt one of the official images if that's preferred. 


It's more of a convenience / safe choice than preferred. We can try out the one you suggested. :)

I like the official version most of the times because it's more likely to be stable/reliable, contain less bloat and have regular updates.

But pgautoupgrade sounds like an interesting project to try out.
I'm happy with either and I can also override it in compose override either way :) So whichever you prefer works for me. 

Resolving patch:
diff --git a/fabfile.py b/fabfile.py
--- a/fabfile.py
+++ b/fabfile.py
@@ -100,14 +100,6 @@ def rollback(commit="HEAD~1"):
     deploy()
 
 
-def backup():
-    with env.cd(env.project_dir):
-        # Manage Backups
-        docker_compose("run django-a python manage.py clearsessions")
-        docker_compose("run postgres backup")
-        env.run("gzip /data/djangopackages/backups/*.sql")
-
-
 def build_and_restart(service):
     docker_compose(f"build {service} --parallel --progress plain")
     docker_compose(f"create {service}")
@@ -143,9 +135,6 @@ def deploy(clearsessions: bool = False, stash: bool = False):
         if clearsessions:
             docker_compose("run django-a python manage.py clearsessions")
 
-        # docker_compose("run postgres backup")
-        # env.run("gzip /data/djangopackages/backups/*.sql")
-
         # stash existing changes
         if stash:
             env.run("git stash")


Test patch:
Repository: djangopackages/djangopackages

Issue:
:tractor: Follow-up issue: Split out "Filter results" on grid view form template into individual fields
See previous issue:

              @lipemorais please push this last template change, and we can complete it. I can update the form to use the form fields individually and skip having crispy forms process it all. (goal is a quick win for you not to create a never-ending issue)

_Originally posted by @jefftriplett in https://github.com/djangopackages/djangopackages/issues/1187#issuecomment-2222979425_
            


Discussion:

Resolving patch:
diff --git a/grid/forms.py b/grid/forms.py
--- a/grid/forms.py
+++ b/grid/forms.py
@@ -1,5 +1,6 @@
 """Forms for the :mod:`grid` app"""
 
+from crispy_forms.helper import FormHelper
 from django.forms import BooleanField, ChoiceField, Form, ModelForm
 from django.utils.translation import gettext_lazy as _
 
@@ -77,3 +78,9 @@ class GridPackageFilterForm(Form):
     sort = ChoiceField(
         choices=SORT_CHOICES, initial=SCORE, required=False, label=_("Sort by")
     )
+
+    def __init__(self, *args, **kwargs):
+        super().__init__(*args, **kwargs)
+        self.helper = FormHelper()
+        self.helper.field_template = "bootstrap3/layout/inline_field.html"
+        self.helper.form_class = "form-inline"


Test patch:
Repository: wger-project/wger

Issue:
BMI And Calorie Calculator Not Working
Using this software in Linux Mint 13.
When I enter my data into either the BMI calculator or the calorie estimator nothing happens.
I have entered my height in cm and my weight in kgs.
The BMI calculator says my BMI = 0.
I'd be happy with 10.



Discussion:
I'll take a look

Hi!

I checked out the BMI calculator and I think that the problem could be with the BmiForm validation. It only accepts decimal for the weight field and and gets the Integer field from the Model.

@dfteam1 did you use a non integer value in the height field?

@rolandgeider Do you think that we can show the form validation errors? I can do it if that is okay.

Yes, the decimal input seems to trigger this. Showing errors is always a good idea, but this form is a bit AJAXy and I would prefer something more general for this. I would suggest that we just fix this specific bug. @rlaszlo do you want to give it a try? If not, I can do it

Yes, I'm working on it now. Should I migrate the UserProfile.height field to Decimal or just add a new Decimal field for the BmiForm?

No, don't migrate the field, better solve it in the form

oh, BTW, if you solve this and make a pull request, send it to my "release" branch


Resolving patch:
diff --git a/wger/nutrition/forms.py b/wger/nutrition/forms.py
--- a/wger/nutrition/forms.py
+++ b/wger/nutrition/forms.py
@@ -55,6 +55,9 @@ def __init__(self, *args, **kwargs):
 
 
 class BmiForm(forms.ModelForm):
+    height = forms.DecimalField(widget=Html5NumberInput(),
+                                max_value=999,
+                                label=_('Height (cm)'))
     weight = forms.DecimalField(widget=Html5NumberInput(),
                                 max_value=999)
 


Test patch: