Corrige o erro ModuleNotFoundError: No module named 'pkg_resources' (solr)

[robertatakenaka]

O que esse PR faz?

Este PR corrige o erro ModuleNotFoundError: No module named 'pkg_resources' que impedia a inicialização do container Django. O problema era causado pela ausência do pacote setuptools em imagens Python 3.11+, onde ele não é mais instalado por padrão. Além disso, o PR atualiza a versão do pysolr para >=3.11.0 no arquivo de requisitos base para garantir compatibilidade e correções de bugs.

Onde a revisão poderia começar?

A revisão deve começar pelo arquivo requirements/base.txt, onde a versão do pysolr foi incrementada, e seguir para os arquivos compose/local/django/Dockerfile e compose/production/django/Dockerfile, onde a instalação do setuptools foi explicitada.

Como este poderia ser testado manualmente?

1. Realize o build das imagens utilizando a flag --no-cache para garantir que as novas instruções do Dockerfile sejam executadas:

docker-compose -f local.yml build --no-cache

2. Inicie os containers:

docker-compose -f local.yml up

3. Verifique se o erro de importação no search/views.py desapareceu e se o servidor Django inicia corretamente.
4. (Opcional) Valide a versão instalada dentro do container:

docker-compose -f local.yml run --rm django pip show pysolr setuptools

Algum cenário de contexto que queira dar?

O pysolr (especialmente em versões mais antigas) utiliza o pkg_resources para gerenciar metadados de distribuição. Como o Python 3.11+ e as novas versões do pip estão removendo a dependência implícita do setuptools, a biblioteca quebrava ao tentar realizar o import logo no início do arquivo views.py. A atualização forçada garante a estabilidade do ambiente de busca.

Screenshots

N/A (Erro de backend/log de console)

Quais são tickets relevantes?

#1361

Relacionado à correção de dependências de ambiente e atualização de busca (Solr).

Referências

• [Python 3.11 Release Notes - Deprecation of standard library removals](https://docs.python.org/3/whatsnew/3.11.html)
• [PySolr GitHub - Metadata and setuptools dependency](https://github.com/django-haystack/pysolr)

---

Deseja que eu ajude a redigir a mensagem de notificação para o Slack ou Discord informando o time sobre este PR?

[Copilot]

Pull request overview

This PR fixes a ModuleNotFoundError: No module named 'pkg_resources' error that prevented Django container initialization. The error occurred because Python 3.11+ no longer includes setuptools by default, and older versions of pysolr depend on pkg_resources from setuptools. The fix involves updating pysolr and ensuring setuptools is available in both local and production Docker environments.

Changes:

• Updated pysolr from version 3.9.0 to >=3.11.0 in requirements
• Added explicit setuptools installation to local and production Dockerfiles
• Added pysolr upgrade step in production Dockerfile

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
requirements/base.txt	Updated pysolr version constraint from ==3.9.0 to >=3.11.0
compose/production/django/Dockerfile	Added setuptools and pysolr installation steps before building wheels
compose/local/django/Dockerfile	Added setuptools installation step before building wheels

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The comment format is inconsistent with the rest of the file and appears incomplete. The comment "# ==80.10.2" seems to reference a version number but is unclear. Based on other comments in the Dockerfile, consider using a format like "# setuptools is required for pkg_resources in Python 3.11+" to explain why this dependency is needed.

Suggested change

	# Garante setuptools disponível
	# ==80.10.2
	# Ensure setuptools is available (tested with setuptools 80.10.2)

[Copilot]

For consistency with the local development environment, consider adding setuptools to requirements/local.txt, similar to how it's specified in requirements/production.txt (line 44: setuptools>=68.2.2). This would make the Dockerfile installation unnecessary and ensure the same version is used consistently. Alternatively, if setuptools installation is needed in the Dockerfile, add a comment explaining why it differs from the production approach.

Suggested change

	# Garante setuptools disponível
	# Ensure setuptools is available for building wheels in the local environment.
	# In production, setuptools is pinned via requirements/production.txt (e.g. setuptools>=68.2.2).
	# For local builds, we intentionally install/upgrade it here because requirements/local.txt
	# does not currently manage setuptools in the same way as production.

[Copilot]

Changing pysolr from an exact pin (==3.9.0) to a floating range (>=3.11.0) means future builds can silently pull newer pysolr releases from PyPI, increasing supply-chain risk and making builds non-reproducible. If an attacker ever compromises the pysolr package or its dependency chain, a simple rebuild could introduce malicious code into your application without any code changes. Prefer pinning a specific, vetted pysolr version here and updating it explicitly via PRs when you want to upgrade.

[Copilot]

The unpinned pip install --upgrade setuptools and pip install --upgrade pysolr commands will fetch the latest versions from PyPI on every image build, so a compromise of those packages or the index could inject malicious code directly into your production image without any code change. Because these upgrades happen outside your pinned requirements and normal review process, they undermine reproducible builds and make it harder to audit exactly which code is running. It is safer to install from your version-pinned requirements (and pin setuptools/pysolr there or in a constraints file) rather than using --upgrade with no explicit version in the Dockerfile.