Tableau Hyper API not installing via pip

[theletterjeff]

When I try to pip install pypeds, the process errors out due to an issue with finding a valid version of tableauhyperapi. The same thing happens when I try to pip install tableauhyperapi==0.0.14401 (the version that Pypeds currently uses), pip install tableauhyperapi==0.0.16491 (current version) and pip install tableauhyperapi.

The same issue pertains to the pantab dependency, which has tableauhyperapi as a dependency.

Expected Result

An error-free installation of pypeds.

Actual Result

The installation errors out with the message:

ERROR: Could not find a version that satisfies the requirement tableauhyperapi (from versions: none)
ERROR: No matching distribution found for tableauhyperapi

System Information

I am on a MacBook Air M2 running MacOS 13.1. This error did not occur on my Windows machine (a Dell XPS13), which suggests that either tableauhyperapi is not compatible with MacOS (unlikely) or not compatible with Apple Silicon (more likely).

Discussion of Solutions

It strikes me that there are two paths forward, both of which raise some high-level questions about pypeds:

1. Leave the tableauhyperapi dependency in, thereby increasing the feature list (launching a Tableau server from within the library) but restricting the platforms from which pypeds can be used, or
2. Take out the tableauhyperapi dependency, which decreases the list of supported features but increases who can use pypeds.

Personally, I would vote for option #2. The Tableau functionality seems out of scope for a library like pypeds--i.e., it seems like something that a user should be able to bolt on if needed, but which is secondary to pypeds core mission of automating access to public higher education datasets.

Could we consider removing the tableauhyperapi and pantab dependencies?

[Btibert3]

In the near term, I think that might make sense. I was trying to cater to the community that might use a flow of Colab -> Build Dataset -> explore in Tableau, but pantab and the lower level dependencies have proven to be less stable than I would have liked or expected.

[theletterjeff]

I think it makes sense to tackle this after getting some good unit tests up. That way we'll know if scrubbing the code of those dependencies breaks anything.

[Btibert3]

I am in alignment; makes sense.