[FEATURE]: Implement support for concurrent installation with `vaab/colour` Pypi package. about colour

[KelSolaar]

I thought about this one and I think there is an easy way to solve it: So basically, our colour is an actual package whilst the Pypi colour package is a single module, it has also not received any updates in a while which probably makes it very stable. With that in mind and because packages do take precedence over module, I think that we should be able to import the colour Pypi module objects into our namespace. I will take a better look but I don't think there will be clashes. It is properly disgusting but it should work.

[KelSolaar]

References vaab/colour#62

[Voultapher]

Assuming it works as intended, I'm fine with the suggested fix. Certainly not clean or pretty, but it would be an improvement over the current status quo.

[Voultapher]

Please let me know once you release a new version that contains the new feature.

[KelSolaar]

In December sometimes ideally, with Python 3.12 compat.

[Voultapher]

After having tried it out, I can confirm it works. However there are some aspects that are not ideal.

1. It's an explicit opt-in, so being spammed with dozens of lines of warnings every time is really not great
   

2. Usually in Python you can set the env variables directly in the import code e.g.:

import os
os.environ["COLOUR_SCIENCE__COLOUR__IMPORT_VAAB_COLOUR"] = "True"


# Has to come first, because it re-imports vaab/colour symbols needed by manim.
import colour

from manim import *

However this does not work here. Because the manim tool imports manim out of control of the user, which forces this property into end users of the tooling. Which I'd like to avoid.

[KelSolaar]

Hi @Voultapher,

We discussed about this with the other Colour developers and it was preferred to have an opt-in behaviour, what we do here is dodgy as hell.

The warnings are admittedly annoying and I will add another environment variable to disable them in a future release.

Because the manim tool imports manim out of control of the user, which forces this property into end users of the tooling. Which I'd like to avoid.

Because it is opt-in, there won't be really other alternatives than either having the user to explicitly enable the injection or provide them wrappers that do so.

Cheers,

Thomas