Reduce mandatory packages bloat

[mborsetti]

I installed the package in a new machine and it installed the following seldom-used packages:

pymeeus, convertdate, korean-lunar-calendar

Any work to reduce (and/or standardize) the number of packaged installed would be helpful to combat package bloat. For example, I have no need for Korean holidays yet I find myself having to install a package that, by its name, is required only for those type of holidays.

[dr-prodigy]

Hi Mike @mborsetti , answers:

pymeeus -> no reference on this package in holidays.. please double-check! korean-lunar-calendar -> currently used for Korea and Vietnam (complex calculations, not an easy task to code it into holidays) convertdate -> you just added a fallback for hijri-converter based on it.. I consider it out of this scope now :-)

Any ideas for the lunar calendar?

[mwheels]

A bit off-topic but on v0.10.4 convertdate was pinned to version convertdate<=2.2.0 witch means that pytz was pinned to pytz<2020

[dr-prodigy]

Hi, sorted out and released to beta with #406 Closing, thx!

[MRigal]

I would also welcome to have less package bloat. One option often considered by other packages ist to add optionals like holidays[lunar] or holidays[full] for convertdate and other advanced converters.

I also guess that many people won't need the full set of possible conversions

[stianjensen]

Moving some deps into optional dependencies that you can choose to install only if you need them would indeed be nice!

[mborsetti]

@dr-prodigy This should probably be reopened to inspire someone to produce a PR

[dr-prodigy]

Hi @mborsetti + everyone! I definitely welcome this idea but, as already shared, holidays itself relies on a pretty limited number of dependencies. Unfortunately, some of those (very often related to specific countries / cultures) require quite a large number of other dependencies, thus introducing some apparently unnecessary bloat. Point is: in order to retain support for all the countries we currently do + provide test coverage for all of them, holidays package definition needs to require those dependencies. A possible solution I have to defeat this constraint could be spinning off some countries and creating a new library like holidays-extras, holidays-lunar or so, depending in turn on holidays + all those usually unnecessary deps.. but I don't feel this as a good choice, because it would have huge impacts on every project currently using holidays. @MRigal @stianjensen @mborsetti any other idea to sort this out? Thx everyone :+1:

[stianjensen]

https://creatronix.de/pip-optional-dependencies/

I think this can be solved with extras_require so that people who need all the calendars can install holidays[extras].

[mborsetti]

Hello @dr-prodigy!

I agree with @stianjensen: https://setuptools.pypa.io/en/latest/userguide/dependency_management.html#optional-dependencies is a great tool for this use case.

Specifically:

1. We can target the dependencies that cause the most bloat and segregate them as optional dependencies to be installed as e.g. holidays[lunar] or holidays[islamic] or holidays[lunar,islamic] or whatever they turn out to be;
2. A small amount of code would need to be added to handle import failures with an explanatory error (e.g. "Could not import korean-lunar-calendar; please install using pip install -U holidays[korea]" or whatever the case may be).
3. No changes would be required for testing other than for this purpose we would install dependencies from a new requirements_test.txt file containing all dependencies, including optional ones;
4. The documentation would need to be updated, and the name of optional dependencies added to the relevant countries.

I wish I had time to volunteer to work on this at the moment, but sadly I don't.

[dr-prodigy]

This sounds very promising @stianjensen @mborsetti thank you both! In fact in the past we managed similar import failures to back-support Python 2.. the same handling could apply to those cases. It doesn't seem to be a very complex work per se, but it requires some structured effort on every side and level of the project (package definition / structure, country-level code, tests, doc).. I will think about it! If anyone is eager to contribute, it would be greatly appreciated! :+1:

[arkid15r]

I guess this can be closed as we've reduced the runtime dependency list to a single package.

[mborsetti]

Truly an amazing job!

👏👏👏👏

(P.S. technically the dependencies are two, korean-lunar-calendar and python-dateutil, but the second one is widely installed.)

[arkid15r]

👍 👍 👍 👍

(P.S. technically the dependencies are two, korean-lunar-calendar and python-dateutil, but the second one is widely installed.)

I believe korean-lunar-calendar was eliminated by @KJhellico in https://github.com/dr-prodigy/python-holidays/pull/1148

[mborsetti]

👍 👍 👍 👍

(P.S. technically the dependencies are two, korean-lunar-calendar and python-dateutil, but the second one is widely installed.)

I believe korean-lunar-calendar was eliminated by @KJhellico in #1148

Ah, yes! The change is still in beta, so missed it.