CI/TST: pip extras install
State: closed

- [x] closes #48942 (Replace xxxx with the GitHub issue number)
- [x] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature


`(c-)blosc` is only available on conda, so removing it from the pip extras
https://www.pytables.org/usersguide/installation.html#prerequisites

Labels:
name: CI
description: Continuous Integration
name: Dependencies
description: Required and optional dependencies

Comments:
blosc on pypi has a lower version than on conda-forge. Pending to see if blosc will be updated on pypi: https://github.com/Blosc/python-blosc/issues/297

EDIT: Updated the OP to note that `blosc` is actually `c-blosc` which isn't available on pypi
Looks like `pip install -e .[...` will still run `setup.py`. Maybe I could patch it to avoid building the extensions?
@phofl found a hacky workaround to not build the extensions and now the jobs complete in a few seconds. Open to better ideas on how to achieve the same thing.
This works consistently? I'd be ok with this for the time being.

Alternative would be to change setup.py directly, correct?
> This works consistently? I'd be ok with this for the time being.

Yeah this worked when I tried in in 05b6ef7e5fd84fccd135a7e1e06981476b0b6b1a.

> Alternative would be to change setup.py directly, correct?

Yeah I think so, but my attempts at this were not successful. I tried creating a `no-extensions` flag to pass into `setup.py` that could be used with `pip install --install-options` (https://pip.pypa.io/en/stable/cli/pip_install/#cmdoption-install-option) but that flag is deprecated and will pass that option to other package's `setup.py`  
Thanks, lets try the current solution and adjust if necessary
@mroeschke I'm not sure if this is adding anything useful to the test matrix. Taking a quick look, this just tests that installing each of the extras works(this is already covered by environment.yml/requirements-dev.txt, since all dependencies are installed when we install from there and these deps are just a subset of thoe), not that the extras are correct. (IMO, you'd need some sort of "golden" file to check this). 

There's also coverage for this in the pre-commit checks which should be enough IMO.

So if it's fine with you, I would propose reverting this PR, since it relies on a setuptools hack that is blocking my meson PR.
Not really, this checks that pip install pandas[foo] works, this is different than the environment yml.
Yeah I think there still some use here smoke testing `pip install pandas[foo]` "works", but agreed there should be a stronger check that install dependencies match what the extras specify.

One concern here was build speed since most of the time was built the cython extensions, but I suppose we can live with some extra build time for now and remove my hack (modifying setup.py in the job) which _should_ unblock your meson PR.

Alternatively do you have any ideas on how to disable building cython extensions when pip installing?
> Not really, this checks that pip install pandas[foo] works, this is different than the environment yml.

Since it's a subset, if we know installing all the dependencies works, then installing only some of them should work too, right?

> Yeah I think there still some use here smoke testing `pip install pandas[foo]` "works", but agreed there should be a stronger check that install dependencies match what the extras specify.
> 
> One concern here was build speed since most of the time was built the cython extensions, but I suppose we can live with some extra build time for now and remove my hack (modifying setup.py in the job) which _should_ unblock your meson PR.
> 
> Alternatively do you have any ideas on how to disable building cython extensions when pip installing?

I came across a rejected issue https://github.com/pypa/pip/issues/4783. It doesn't seem like it. 

Why don't we restrict these builds to PRs tagged with "Build" for now? That should be a good compromise.
> Why don't we restrict these builds to PRs tagged with "Build" for now? That should be a good compromise.

Sure that would be fine with me