Skip to content

ci: make index pypi default and pythonanywhere explicit and setup python through uv#613

Open
gsprochette wants to merge 2 commits intomainfrom
ci/set-python-version-and-avoid-http-errors
Open

ci: make index pypi default and pythonanywhere explicit and setup python through uv#613
gsprochette wants to merge 2 commits intomainfrom
ci/set-python-version-and-avoid-http-errors

Conversation

@gsprochette
Copy link
Copy Markdown
Collaborator

@gsprochette gsprochette commented Apr 3, 2026

Description

This PR attempts to improve the installation of pruna in the CI which has been systematically crashing in the "installation" workflow recently. It changes two things:

  1. the python version was inconsistant, manually setup in each worflow which is redundant with the later uv setup. I merged the two steps by passing a python-version input to the setup-uv-project action
  2. I reworked the pyproject.toml, more details below

Behavior of the pyproject.toml before: index-strategy = "unsafe-best-match": Search for each package across all indexes, and select the best version from the combined set of candidate versions.

Behavior of the pyproject.toml before: index-strategy = "first-index" which is the default for uv.
In essence, what I changed was making the pruna_internal index (and also intel) explicit, meaning that this index will only be searched if we explicitely state so.
In practice, this means that pythonanywhere will only be pinged for stable-fast-pruna extra or for the gptq extra. For all other packages, only the pypi index exists.

I do not know if this will solve the HTTP errors we've been getting, I think we will ping pythonanywhere much less often in the very least, and that the error message will be clearer (currently it always state that it could not find a random package different each time on pythonanywhere, even though it should come from pypi).

Related Issue

Fixes #(issue number)

Type of Change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

How Has This Been Tested?

I've installed a few combinations of extra, and in particular I ran uv sync --extra dev --extra lmharness --extra vllm which is the line that fails in installation tests.
However, this command already passed before doing these changes so I do not know if it fixes the issue.

I also tried pip install -e .[dev,lmharness,vllm] to make sure this is also working without uv. pip doesn't read the tool.uv section anyway so if it needs the extra index it must be passed explicitely pip install pruna[stable-fast-pruna] --extra-index-url https://prunaai.pythonanywhere.com/simple/ anyway, but good to know it still works

Checklist

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes

Additional Notes

@codacy-production
Copy link
Copy Markdown

codacy-production bot commented Apr 3, 2026

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

TIP This summary will be updated as you push new changes. Give us feedback

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant