Don't fail if pyarrow is not installed.

[thetorpedodog]

Since this doesn't directly depend upon pyarrow, it is possible that some end-user code does import pyarrow_hotfix as a defense mechanism, despite not needing pyarrow_hotfix itself. If this happens, it should not be a failure.

---

This is a simple proposal to take or leave; it also may be reasonable to add a warning that Arrow isn’t installed.

[pitrou]

I don't have a strong opinion on this, but I'm a bit wary of potential mishaps due to silently silencing the error. Since this is a security feature, I'd rather be strict here.

cc @jorisvandenbossche for opinions

[jorisvandenbossche]

An advantage of this is that it makes it easier to adopt in case you only have an optional dependency on pyarrow; you can just import it without having to care about pyarrow being available or not.

However, I think it is also rather easy to get this as well by just only importing this where you import pyarrow (at least for a library depending on the hotfix package, that should be easy I think).
So for that reason, this might not be needed. @thetorpedodog you are more thinking about end-users rather than library developers?

[thetorpedodog]

The case I am thinking of is generally the "second-level" dependency of Arrow on the part of either a library developer or an end developer.

Let's say that I as a library developer have my_library that depends upon other_library that depends upon pyarrow. other_library is rarely maintained and (for whatever reason) has a restrictive Arrow dependency. my_library is targeted at users who are not primarily developers (e.g. scientists). I want to provide library users with a secure-by-default installation, so I put import pyarrow_hotfix in my_library/__init__.py.

If other_library is updated and no longer requires pyarrow, suddenly my_library starts crashing, despite the fact that users are no less secure than before.

Similarly, if I as an end developer depend upon other_library in its insecure state, if other_library drops its Arrow dependency entirely, my program suddenly breaks. While it is easier for me to fix (just remove the import from my main module), it is still strange that a security fix caused my program to stop working even though it doesn't have a direct dependency.

Both of these may be somewhat of corner cases, and honestly I completely understand if you would prefer not to accommodate them directly for other reasons.

Alternately, a really short justification might be "if your library does not depend upon another library, the other library's absence should not cause any problems," but again I understand that this particular library is kind of a special case.

Either way, hopefully this at least makes clear what was going through my head when writing this.

[jorisvandenbossche]

Personally I am fine with this change if it helps adopting the hotfix package.
I think silencing the potential import error shouldn't be much of a problem, because this only would be a problem if you actually use pyarrow, in which case you do another import of pyarrow which will then raise the ImportError anyway?

[pitrou]

Ok, if this is desirable, can a test be added for it?

[pitrou]

Should this be ModuleNotFoundError?

[thetorpedodog]

Good idea. Changed here and below.

[thetorpedodog]

Test added as well.

[thetorpedodog]

Good idea. Changed here and below.

[pitrou]

Ow, sorry: ModuleNotFoundError appeared in Python 3.6. A fallback is needed for 3.5...

[thetorpedodog]

Ow, sorry: ModuleNotFoundError appeared in Python 3.6. A fallback is needed for 3.5...

one more round!

[pitrou]

Thanks @thetorpedodog ! I've released 0.6 with this change.