Remove deprecated packages as dependencies in requires-install.txt

[anders-kiaer]

When dash==2.0 was introduced, the packages dash_core_components, dash_html_components and dash_table were deprecated, in favour of dash.dcc, dash.html and dash.dash_table.

Still, these packages are pinned as mandatory dependencies in

dash/requires-install.txt

Lines 4 to 6 in 6ee3eee

	dash_html_components==2.0.0
	dash_core_components==2.0.0
	dash_table==5.0.0

even though they are deprecated. As downstream user I can't currently avoid installing these, even though I use the new import syntax.

The downsides by being forced to install them are mainly:

• Increased installation time. The new releases of dash has wheels 🎉 - which semi-closes Deploy dash* wheels to PyPI on releases #1440. However, since the deprecated packages currently also are installed along with dash, and they use the inefficient/problematic source .tar.gz distributions only, the problem still remains.
• Difficulties with communication during debugging. If the user has a problem with dcc and only give/list dash_core_components version you don't know which version of dash.dcc is actually used, since dash_core_components has a final "release" always pointing to the latest dash.dcc version.

Suggested solution:
This already used feature in setuptools

dash/setup.py

Line 19 in 6ee3eee

packages=find_packages(exclude=["tests*"]),

can be used to install multiple top level packages from the same setup.py. So if basically one file per deprecated package is created in this repository:

dash_core_components/__init__.py
dash_html_components/__init__.py
dash_table/__init__.py

which can be copied from the relevant file in the deprecated repositories, the user will then with pip install dash still get the deprecated packages installed in the namespace (such that the deprecated import syntax still works), but we avoid fetching + installing the deprecated packages from PyPI (which also only offer source distributions and not wheels).

Benefits:

• Reduced installation time (we can close Deploy dash* wheels to PyPI on releases #1440).
• Less risk of misunderstanding (currently it could at first glance look like you have "two versions" of e.g dash_core_components - one explicit named package and one under dash.dcc).
• pip list will only list dash and not the deprecated packages, which is also the correct thing to communicate today when it is a monorepo.

[alexcjohnson]

Thanks for pointing out the lack of wheels @anders-kiaer - I've created wheels for the dash-core-components, dash-html-components, and dash-table stubs, so that should improve the installation time at least.

The reason we included these as required dependencies is so that anyone still using the old imports will necessarily get the new ones, regardless of how they've installed these packages. In particular, the solution of multiple top-level packages has problems if a user has a requirements file that explicitly lists dash-core-components etc, perhaps due to a pip freeze. I don't believe there's a way to get pip to reconcile such a situation, it will install one package on top of the other, quietly obliterating the other one.

When Dash 2.0 was new, it was important to us that the old usage not throw an error, just a warning. At some point though we'll probably decide users have had long enough to update, and throwing an error is acceptable. Then we can stop installing these stub packages entirely and detect the old ones here when they're registered and throw an error:

dash/dash/development/base_component.py

Lines 35 to 36 in 58bec06

	component = abc.ABCMeta.__new__(mcs, name, bases, attributes)
	module = attributes["__module__"].split(".")[0]

But I don't think we're quite ready for that yet. Maybe there'd be a way to swap out the old for the new during this registration, in which case we could make this still be a warning? My gut reaction is that could be even more confusing than what we do today, but if you (or anyone else) would like to try it out I'd be happy to take a look.

[anders-kiaer]

In particular, the solution of multiple top-level packages has problems if a user has a requirements file that explicitly lists dash-core-components etc.

That is a good point. 🙂

Thanks for the wheels. Having wheels now for dash-core-components and the other deprecated packages improves the Docker installation time (and some strange, semi-random pip install failures). In my opinion that is good enough while we wait for the them to be removed as Dash dependencies.

[ryanskeith]

This seems to still be a problem.