search

scientific-python / lazy-loader

Populate library namespace without incurring immediate import costs
BSD 3-Clause "New" or "Revised" License
132 stars 20 forks source link

Creation of a linter/checker? #89

Closed trexfeathers closed 6 months ago

trexfeathers commented 8 months ago

Hi,

We've been looking at using lazy_loader in one of our projects: bjlittle/geovista#669

Something that concerns me is that every developer, or at least every reviewer, needs to be on board with using these patterns. Anyone who is unaware of the use of lazy imports is likely to start introducing 'eager' imports whenever they write new code.

This seems a prime case for some sort of linter that could be run during CI tests or as part of a pre-commit hook. Is this an ambition that has been discussed at all? I couldn't find anything from a quick search.

I appreciate that everyone's time (myself included) is limited, so I'll understand if the answer is "Yes, but No" 😁

Thanks

stefanv commented 8 months ago

Hi @trexfeathers, the primary way we use lazy_loader is to make subpackages load on request. What you do inside those subpackages (lazy or not) doesn't matter nearly as much. It doesn't have to be "turtles all the way down" to get the benefit.

In that light, I think it's OK if the library authors familiar with lazy loading do the first layer (subpackages, one level deep) and accept further contributions without worrying about it too much.

stefanv commented 6 months ago

This type of rule may be best implemented in an external tool such as ruff.