[stevepiercy]

Closes issue

• Closes Switch to uv for development #1102

Description

Switch to uv for development.

Update documentation with new commands.

Checklist

• I've added a change log entry to CHANGES.rst.
• I've added or updated tests if applicable.
• I've run and ensured all tests pass locally by following Run tests.
• I've added or edited documentation, both as docstrings to be rendered in the API documentation and narrative documentation, as necessary.

---

📚 Documentation preview 📚: https://icalendar--1315.org.readthedocs.build/

[read-the-docs-community]

Documentation build overview

📚 icalendar | 🛠️ Build #32284923 | 📁 Comparing e85f7e2 against latest (f0ba179)

  🔍 Preview build  

5 files changed · ± 5 modified

± Modified

• 404.html
• contribute/development.html
• reference/changelog.html
• contribute/documentation/build-check.html
• contribute/documentation/index.html

[stevepiercy]

@niccokunzmann I can't remember what we did to fix this error https://github.com/collective/icalendar/actions/runs/24280322355/job/70901092097?pr=1315#step:6:74. Do you remember?

[niccokunzmann]

warning: icalendar defines settings for uv_build in tool.uv.build-backend, but uses hatchling.build as build backend instead

This is one indicator.

Because only sphinx-icalendar<=0.1.0 is available and
      sphinx-icalendar==0.1.0 depends on your project, we can conclude that
      sphinx-icalendar>=0.1.0 depends on your project.
      And because icalendar:dev depends on sphinx-icalendar>=0.1.0 and your
      project requires icalendar:dev, we can conclude that your project's
      requirements are unsatisfiable.

      hint: The package `sphinx-icalendar` depends on the package `icalendar`
      but the name is shadowed by your project. Consider changing the name of
      the project.

These are our edits for the problem:

• https://github.com/collective/icalendar/pull/1268/changes#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711R301
• https://github.com/collective/icalendar/pull/1254/changes#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711

I think, it somehow instructs UV to use icalendar from that source.
Fetching tags was one idea but that should not be it, really.

Also the clash between uv and hatchling is something I don't know much about. We could also change from hatchling to uv as a build backend. I am not attached. The only thing that I like having is the ability to release a new version based on tags. But that could be possible anyway with this: https://stackoverflow.com/a/32965521/1320237, so we can keep the same interface we have having at the moment, with icalendar.version.

[niccokunzmann]

Thanks for doing the big load. Whenever you feel like it, I can start tinkering with this branch :)

[niccokunzmann]

The test environment should not need the sphinx-icalendar package.

[niccokunzmann]

The tests are running. We need to open an issue that the pytz tests are not working.
Or, we can just remove the nopytz tests fully and remove the tox dependency.

[stevepiercy]

Please see my suggestions and questions.

[stevepiercy]

The tests are running. We need to open an issue that the pytz tests are not working. Or, we can just remove the nopytz tests fully and remove the tox dependency.

Sorry, I don't understand which would be better.

Do we need nopytz tests? Removing tests would not remove the feature, but would remove testing the absence of the feature. Additionally, the feature has been deprecated since 6.0.0, although we said it "may still be used" per https://icalendar.readthedocs.io/en/stable/how-to/upgrade.html#pytz-support.

I think we should announce that pytz support will be removed in 8.0.0, since that would be a change in the promise. I think that we should make an announcement in the 7.0.4 release that pytz support, deprecated since 6.0.0, shall be removed in 8.0.0. That would give fair warning.

Does that help?

[niccokunzmann]

This is good to go.
@stevepiercy have a final look if you like and merge it if you are satisfied!

[niccokunzmann]

Does that help?

Yes, that helps. There is the pytz issue and it is good if we drop pytz. It is outdated now. #1101 - can you update that on how you would like this to go or put in a PR?

[stevepiercy]

Does that help?

Yes, that helps. There is the pytz issue and it is good if we drop pytz. It is outdated now. #1101 - can you update that on how you would like this to go or put in a PR?

Updated!

#1101

Please feel free to edit the description.

[stevepiercy]

@SashankBhamidi would you please do a review, per your request? I think this is ready to merge.

We decided to defer the replacement of tox with uv for another PR. This PR moves us forward, and makes it a lot easier to get started for contributors.

[SashankBhamidi]

Thanks! Few comments:

[stevepiercy]

@SashankBhamidi thanks for the review! I double-checked make test TOX_ENV=py310 as well as for py314 and no TOX_ENV, and it works as I expect, but if it doesn't work for you, then please open an issue.

I'm going ahead and merge this monster. Thanks everyone!

[SashankBhamidi]

@stevepiercy You're right, apologies.

I didn't actually test the command locally. Thanks for the patience.

[SashankBhamidi]

Perfect.