Conversation
|
Hmm, build is hanging on |
victorlin
force-pushed
the
victorlin/sync-python-deps
branch
from
753d1c0 to
f3cc445
Compare
|
Can't merge this due to the failing build. I opened an issue to investigate further: #119 |
victorlin
force-pushed
the
victorlin/sync-python-deps
branch
2 times, most recently
from
06810d8 to
ed47306
Compare
| - perl | ||
| # Pin pulp <2.8 for snakemake: https://github.com/snakemake/snakemake/issues/2607 | ||
| - pulp <2.8 | ||
| - pyarrow |
There was a problem hiding this comment.
Hmm, just realized this downgrades evofr in the CI summary. I'm guessing this is due to some dependency resolution for jax/jaxlib.
The evofr dependency specs were fixed in bioconda/bioconda-recipes#40779 which was released with v0.1.18 build_1. Looks like the build chose v0.1.18 build_0, so we might have to specify evofr >=0.1.19 for the dependencies to resolve correctly.
There was a problem hiding this comment.
And of course the CI builds are hanging again...
There was a problem hiding this comment.
Good call on checking the CI summary, I'll try to do that more in the future.
In this case, it looks like evofr's tight pins around its dependencies from the linked bioconda PR are making it harder to resolve versions that work across all packages and their dependency pins, more notably in macos-13 (which took 40 minutes compared to 5 minutes on the latest stable run) and ubuntu-22 (which has been running for 47 minutes and counting).
I wonder if it's possible to relax evofr's tight pins by testing compatibility with newer versions. For example, the latest version of jax is 0.6.2. My speculation is that it's not allowed only because it wasn't tested at the time of pinning to 0.4.x. If it actually works fine with the latest version, the pin should be relaxed.
There was a problem hiding this comment.
ubuntu-22 eventually succeeded at 1hr 19min 😬
I believe the pins for jax are pretty tight because they use effort-based versioning, where any version bump can introduce breaking changes.
There was a problem hiding this comment.
I get that, and if the intent of the evofr pins is to avoid any potential breaking changes, the pin should be even tighter capping at an exact 0.X.Y version rather than allowing any new Y as it currently does.
My point is that newer versions should be regularly tested, and for versions with no breaking changes, the pin updated to support it (e.g. nextstrain/augur@e6a57b9). I don't know anything about evofr's usage of its dependencies, but support for newer versions would avoid the significant slowdown in dependency resolution experienced here.
There was a problem hiding this comment.
This would require changes in evofr, so I've opened blab/evofr#56
Pin minimum version for correct dependency resolution otherwise evofr will get downgraded to v0.1.18 build 0 <#117 (comment)>
This was added to docker-base in nextstrain/docker-base@2904f40
This was added to docker-base in nextstrain/docker-base@ca8a6fa
Pin minimum version for correct dependency resolution otherwise evofr will get downgraded to v0.1.18 build 0 <#117 (comment)>
victorlin
force-pushed
the
victorlin/sync-python-deps
branch
from
2f8c99f to
5ad043a
Compare
|
I've split the c-ares update into a separate PR since that change is not blocked: #120 |
3 participants
Description of proposed changes
Add openpyxl and pyarrow. These were added to docker-base in:
Checklist
Update changelogno changelog here