feat: Migrate to uv from pipenv

[DhavalGojiya]

Description

Migrated from Pipenv to uv

Added support for pyproject.toml with uv

Removed files:

setup.py
setup.cfg
MANIFEST.in
Pipfile
Pipfile.lock

---

uv build or pipx run build

Source Distribution

Wheel Distribution

[ulgens]

Thank you so much for this. I was plannign to handle the CI pipeline first, then come to this but that order is not a strict requirement.

[DhavalGojiya]

I also think we should drop support for Python 3.8 and Python 3.9 for this package, as they are already EOL before this uv PR is merged.

I checked the test cases and noticed that they use the pytz package and it is also not available by default (Third party library).

Since Python 3.9+ introduced the zoneinfo library, we can replace pytz with it.
We can proceed step by step.

Any thoughts, @ulgens?

[ulgens]

I also think we should drop support for Python 3.8 and Python 3.9 for this package, as they are already EOL before this uv PR is merged.

I was trying to keep an overlap for supported Django - Python versions between the latest release and the next one, so that the update process will be less painful for the users but I just removed django<4.2 yesterday (the latest release was supporting <=4.1) to have a better experience with the CI testing adoption. Removing 3.8 and 3.9 is definitely possible, but I don't want to prioritize it if it's not absolutely necessary.

I'm okay with adding pytz depedency for a temporary period.

[DhavalGojiya]

I also think we should drop support for Python 3.8 and Python 3.9 for this package, as they are already EOL before this uv PR is merged.

I was trying to keep an overlap for supported Django - Python versions between the latest release and the next one, so that the update process will be less painful for the users but I just removed django<4.2 yesterday (the latest release was supporting <=4.1) to have a better experience with the CI testing adoption. Removing 3.8 and 3.9 is definitely possible, but I don't want to prioritize it if it's not absolutely necessary.

I'm okay with adding pytz depedency for a temporary period.

👍

[DhavalGojiya]

Update:

• Added pytz to the dev dependencies temporarily
• Rebased successfully with the latest project state
• Updated classifiers

[ulgens]

Thanks for the update.

About pytz, is it useful now? Were you able to run tests locally, or does the project itself depend on it? If not, I'd recommend adding the pytz where it's useful.

Do we still need ez_setup.py file?

[DhavalGojiya]

Thanks for the update.

About pytz, is it useful now? Were you able to run tests locally, or does the project itself depend on it? If not, I'd recommend adding the pytz where it's useful.

Do we still need ez_setup.py file?

Currently working on it (test cases)

[DhavalGojiya]

ez_setup.py

We don't need this file anymore, also it's too complex.

[DhavalGojiya]

@ulgens
I think we can proceed with this setup as soon as possible.
I have a few more PRs in mind over the next few weeks to modernize this library + test cases.

[DhavalGojiya]

@ulgens
Let me know if anything is missing here.

I have plans to create a Docker-based, fully automated test setup for this package this weekend. I expect this PR to be merged before then, as uv really helps us set up and run test suites very easily without any hassle.

[ulgens]

Hey @DhavalGojiya , sorry for the delay on my end. I don't use Django as much as before, and I have very limited time to push anything related to it - but I should've responded a long time ago.

My memory about this PR was that because the tests are not working yet, anything else we change can not be tested either. The PR looks pretty much okay, and I think we can merge it but it's not clear if this new setup works fine and what will happen when someone needs to make a new release.

About the docker-based test setup, can you please create an issue first? I'm missing why it's needed.

[DhavalGojiya]

what will happen when someone needs to make a new release?

I understand that this PR does not directly fix that issue, but we can take things step by step. If someone wants to contribute to this package, the first step is setting up the project and its dependencies. This PR addresses that problem, and uv makes it much easier to set up the project in a local environment.

anything else we change can not be tested either

This PR does not change any code that affects the package itself or the code that is shipped to PyPI. I don't think this is something we need to worry about for this PR.

can you please create an issue first?

This is already covered by an existing issue in the project: #249

About the docker-based test setup, can you please create an issue first? I'm missing why it's needed.

Check this setup (I wrote this entire test module for Haystack-related projects):
https://github.com/django-haystack/pysolr/blob/master/docker/docker-compose-solr.yml

To run the drf-haystack test cases, we currently need to do this steps:

1. Set up an Apache Solr or /Elasticsearch instance (Docker)
2. Need to create core/index.
3. Configure the schema files (for Solr). These schema files are generated from search_indexes.py (django-haystack)
4. Reload or refresh the Apache Solr instance after schema changes.
5. After this we can run this package test cases.

I don't think we can cover all of this in a single PR. We'll need to address these step by step, and I can help with this.

[ulgens]

but we can take things step by step

I definitely agree on that, but the part I am focused on is that the previous setup was working at some point, and switching to a new method that is not validated yet is risky. I'd prefer keeping things as is, instead of providing untested new structures.

This PR does not change any code that affects the package itself or the code that is shipped to PyPI.

The PR is changing the dependency management and the build system, I'm missing how it doesn't affect the build process.

This is already covered by an existing issue in the project: #249

#249 has no mention of docker in it. The case sounds like it makes sense, but it will still need an issue. Also, the latest issue with tests wasn't the environment; it was the code.

[ulgens]

I'd recommend depending the higher limit too.

[DhavalGojiya]

< 3.14?

[DhavalGojiya]

but the part I am focused on is that the previous setup was working at some point, and switching to a new method that is not validated yet is risky. I'd prefer keeping things as is, instead of providing untested new structures.

The current setup is using elastic-version: ["1.7", "2.4", "5.5", "7.13.1"]. All of these Elasticsearch versions have reached EOL. See: https://endoflife.date/elasticsearch

Only Elasticsearch 8.x and 9.x series are currently maintained. There is also one more major problem here.

This drf-haystack package depends on django-haystack, and django-haystack currently does not support the actively maintained Elasticsearch 8.x and 9.x series. (This is the biggest issue.)

When I say django-haystack does not support the latest maintained Elasticsearch versions, it does not mean that django-haystack cannot be used in a project running the latest Elasticsearch versions. However, there is a high chance that things may start breaking due to the major Elasticsearch version changes, since django-haystack does not officially support them.

django-haystack also does not officially support the latest maintained Apache Solr 9.x and 10.x versions, but we are using Solr 9.x with django-haystack in six company projects, and all of them still work fine, with almost all features functioning correctly with django-haystack + drf-haystack.

@acdha (maintainer of django-haystack) and I are currently working on these packages to keep support for newer maintained search engines (Specially Apache Solr) available in the django-haystack , pysolr package.

drf-haystack does not care whether we use Elasticsearch or Apache Solr as the search engine, because that responsibility belongs to its upstream dependency, django-haystack.

drf-haystack just provides serializers that work with the SearchQuerySet returned by the django-haystack package.

The PR is changing the dependency management and the build system, I'm missing how it doesn't affect the build process.

I would say that we are just optimizing the build process (setuptools --> hatchling) rather than changing any components. Honestly, setuptools is a horrible tool to work with.

It does not matter which build frontend or build backend we use for package management. At the end, the generated source distribution and wheel distribution are the same.

We do not change anything in the pyproject.toml -> [dependencies] section in this PR, and that is the only configuration that gets stored in the wheel distribution along with the project metadata.

The case sounds like it makes sense, but it will still need an issue. Also, the latest issue with tests wasn't the environment; it was the code.

Yes we can create a new issue or can create sub task in existing issue since this docker things also part of test process.