asciitree has no wheels

[Carreau]

Zarr version

all

Numcodecs version

NA

Python Version

all

Operating System

all

Installation

pip install --only-binary ':all:' zarr

Description

Zarr depends on asciitree, which does not publish wheel.

When trying to install and avoiding tar.gz for various reasons this make it harder to install zarr.

The --only-binary ':all:' is useful in CI to make sure that binary artifact are available for all dependencies and usually to make sure the end user does not need to have a compiler. In some cases, you may want to ensure all your dependencies have wheels as you do not want code execution at install time. Plus, even for python, wheel install is usually faster, and dependency resolution does not need to run setup.py.

Because if depends on asciitree, zarr is one package cannot be installed with --only-binary ':all:' flag, and contaminate all the dependees. (you can use --no-binary asciitree to work around this specific dependency so not critical)

It would be great zarr would only rely on packages that have wheels.

As asciitree seem unmaintained, as author does not resond to issue asking for wheels, nor have seen a commit in 3years.

This is likely because its feature complete?

So solution might be:

• Vendor asciitree
• Repackage with wheel under a different package name (but same import name).
• Custom code.

Steps to reproduce

$ pip install --only-binary ':all:' zarr
Collecting zarr
  Using cached zarr-2.14.2-py3-none-any.whl (203 kB)
  ...
  Using cached zarr-2.5.0-py3-none-any.whl (131 kB)
ERROR: Cannot install zarr==2.10.0, ... zarr==2.9.4 and zarr==2.9.5 because these package versions have conflicting dependencies.

The conflict is caused by:
    zarr 2.14.2 depends on asciitree
    ...
    zarr 2.5.0 depends on asciitree

To fix this you could try to:
1. loosen the range of package versions you've specified
2. remove package versions to allow pip attempt to solve the dependency conflict

ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflicts

Additional output

No response

[Carreau]

This would be helpful for napari, and I'm using the --only-binary ':all:' in napari in CI to make sure that .whl are available for all our dependencies before marking napari compatible with Python 3.11. asciitree is the second-to-last dependency that does not have wheel.

[d-v-b]

maybe we could drop asciitree in favor of rich

[Carreau]

Sure, I dont know how much rich is supported in notebooks, and I assumed you wanted to keep dependencies small maybe ?

[jakirkham]

Is this the only issue one runs into or just the first one?

[d-v-b]

i think we could use rich to implement an html_repr that would be an even better viz experience for notebooks. And rich itself seems pretty lightweight in terms of dependencies.

[Carreau]

Is this the only issue one runs into or just the first one?

Sorry, I'm confused about what what this asks.

The only issue is that anything depending on zarr can't be installed with --only-binary :all:.

[jakirkham]

Rephrasing, do other dependencies of zarr also lack binary wheels and pip is just failing on the first one it sees (asciitree)? Or are there wheels for all other dependencies and only asciitree lacks one?

[Carreau]

As far as I can tell for zarr dependencies , asciitree is the only dependency that does not provide any wheel at all (and is pure python, so it would be trivial to have 1 universal wheel).

It's another story for binary deps for example numcodecs does not provide an osx arm64 wheel, but that's "just" a matter of trying to fix that for numcodecs.

[johanvdw]

Just adding that this indeed complicates (offline) installation.

Eg when fetching packages using pip-download, all dependencies are present as whl files but asciitree is not, which makes it uninstallable because compilation does not work nicely offline.

[Carreau]

You could also ask the author – and if not responses – Pypa to take over the package, and just publish a wheel.