Options for installation without Scipy?

[djhoese]

I've found the advanced section that discusses the requirement of scipy and how to work around it:

https://colour.readthedocs.io/en/latest/advanced.html#using-colour-without-scipy

But I have a package that only needs the colorspace conversions (specifically RGB to HCL and HCL to RGB) and only depends on numpy and pillow otherwise. Since most of our users are installing from PyPI or conda-forge it isn't really an option (unless I'm missing something) to install colour-science without the large scipy dependency coming along for the ride.

I'm wondering if anyone has other options or ideas for what could be done to get the colorspace conversion functionality without the scipy dependency, but in a library use case where the user won't be manually installing colour. What are the chances of splitting colour into more packages? Or making scipy an optional dependency again (maybe with better import/error handling)?

Thoughts?

[KelSolaar]

Hi @djhoese,

What are the chances of splitting colour into more packages?

It makes maintenance a huge burden, and it is already quite high: colour-demosaicing, colour-hdri, colour-datasets and colour-checker-detection are separate and it takes a few days to release the entire stack because of that separation.

Or making scipy an optional dependency again (maybe with better import/error handling)?

There is no plan to make Scipy optional to install again at this point. We rely on quite a bit of functionality of it now, especially in the colour.colorimetry core sub-package and this is a trend that keeps increasing.

Have you considered installing from Github directly? https://stackoverflow.com/a/15268990/931625

Cheers,

Thomas

[djhoese]

Thanks for responding @KelSolaar. I'm not sure how installing from github source changes the fact that scipy is listed as a hard requirement in the setup.py. The only way to do this custom install without scipy would be to do pip install git+https://... --no-deps, but that means not getting any of the non-scipy requirements installed. Let me know if I'm missing something but I don't see a way to install colour-science and still use these lower level functions without scipy installed.

The only other option I can think of besides "just deal with it" are to copy the necessary code to our package (BSDv3 should allow this with copyrights retained).

One question about the package maintenance burden of splitting the package would be that I'd hope this newer package (colour-colorspaces?) would be pure python and wouldn't need as much updating as the other packages, but that assumes I know anything about how this code is intertwined and I don't. 🤔

[KelSolaar]

Yes, I was thinking about installing without dependencies. The other hard requirements are numpy and imageio, the former I'm guessing is already a requirement for you and the latter if you have pillow is probably not too heavy. In order to use colour, you would still need to mock scipy though but it is maybe something we could actually handle in the main __init__.py file to make that easier.

copy the necessary code to our package (BSDv3 should allow this with copyrights retained).

That would work for sure!

would be pure python and wouldn't need as much updating as the other packages

It would require Numpy at the very least and it depends on quite a lot of other stuff, e.g. colour.colorimetry, colour.algebra, colour.utilities, etc...

[djhoese]

Yes, I was thinking about installing without dependencies.

Yeah the main complication here is for the users of our library where they'll want to do pip install our-library and we need to list something for the dependencies. There isn't really a way to do that (even if we pointed to the github source) without getting all the hard requirements. Similarly, our users typically use conda via conda-forge where you also can't really say "install this library but none of its dependencies". Put another way, it is easier to add on optional dependencies (ex. setuptools extras via pip install contour-science[specialalgorithms]) than it is to remove a hard dependency.

It would require Numpy at the very least and it depends on quite a lot of other stuff, e.g. colour.colorimetry, colour.algebra, colour.utilities, etc...

If the package is pure python the numpy dependency doesn't add too much complexity as it will be easy to install with its binary wheels. As long as the code of this separate colour package doesn't require compilation (Cython/C extensions, etc) then the released PyPI file comes down to a single sdist tarball. Regardless, you're right and I completely understand not wanting to add to the maintenance burden of managing a ton of extra packages. I could imagine a larger restructuring of the packages in the colour ecosystem which would allow users to limit what needs to be installed depending on what they specifically want to do...but this restructuring would probably not be a small undertaking. Something like high-level algorithm packages that all depend on a core package which includes "the basics", but I'm very out of my depth as far as the science you are trying to accomplish so I'm not going to pretend I know what's best for your community/ecosystem.

Thanks for your time and responses. I'll see what I can do to get some high quality RGB conversions into my library.

[KelSolaar]

Is the issue with Scipy the size of the wheels?

[djhoese]

Good question. I guess that yes it is the size of the wheel. I also assumed that scipy had a lot of extra dependencies but it looks like numpy is the only one. I'm not sure if scipy installs any extra files at install time. I do eventually have to bundle my environment into a small tarball but it looks like something else is pulling scipy in already. Maybe it was just a purity thing that it seemed unfortunate to need such a small portion of this package and get scipy without needing it. But...maybe this is something I can worry about later. Maybe I'll just ignore this for now. Thanks for listening to my ramblings.