Replies: 2 comments
|
The simplest way to avoid a stale nightly wheel is to don’t lock the nightly package. [feature.pyarrow-nightly.pypi-dependencies]
pyarrow = { version = "*", index = "https://pypi.anaconda.org/scientific-python-nightly-wheels/simple", no-lock = true }When the CI runs you can keep |
|
For that CI job, skip the setup-pixi install ( If setup-pixi installs first, you still 404 on the pinned wheel. Don't commit the lock from CI. Keep
|
Uh oh!
There was an error while loading. Please reload this page.
Summarizing the issue from pandas-dev/pandas#65690 (comment):
We generate a lock file that specifies a nightly version of pyarrow like 25.0.0.dev59. This nightly version auto-increments number after
devand the nightly pypi index eventually evicts older pyarrow versions.The issue then is that our lock file will eventually reference a nightly wheel version that no longer exists. Of course updating the lock file regularly is a solution, but I am curious if there are better, alternative solutions to this with a lockfile workflow. In theory we want any nightly wheel version that exists on this index.
This workflow is run in Github Actions, so I don't think caching a nightly wheel longer term is viable across all the jobs from all the pull requests that are run.
All reactions