7 ms·

I think this import flow tends to be the canonical one. I might recommend doing something like importing from something like `numpy.version` (or some other "ra

by rtpg 13d ago

I think this import flow tends to be the canonical one. I might recommend doing something like importing from something like `numpy.version` (or some other "random" very small utils package) so that the work done on file load is still fairly small.

dataflow 12d ago
It's not clear such a thing even exists in general though. It's certainly not guaranteed by packages. What would that be for numba?
- rtpg 12d ago
  Yep it's not clear, and a bit of a case-by-case thing. Fortunately most codebases only need to do this in a handful of spots so you can really "just" look at a package and find a file that probably is safe. For example, numba._version only imports standard library stuff so is probably good enough here[0] It would be nice to have general querying capabilities here, of course. I just think that in practice there's at least a halfway-decent workaround in almost any real situation [0] https://github.com/numba/numba/blob/main/numba/_version.py https://github.com/numba/numba/blob/main/numba/_version.py
zbentley 12d ago
Common? Yes. Canonical/ideal? No. Optional dependency specifiers in your package metadata is a much better way to go. You can use those even if you don't publish your package as an artifact; `pip install -e .[optional-thing]` should work, or can be made to, easily.
- rtpg 12d ago
  That's only part of the puzzle. Your program needs to branch on whether the dependency is installed or not! "Oh you don't have optional dependency? Then do X" needs to happen at runtime right?
  - zbentley 9d ago
    I explained further here: https://news.ycombinator.com/item?id=49604462 https://news.ycombinator.com/item?id=49604462 In my preference order: an explicit CLI option/envvar which requires the optional dep, a flag file on the filesystem, or an ImportError attempt if you absolutely must. Use a stub/trampoline file in the conditionals so that static analyzers and laziness analysis on that file itself still work.

by rtpg 13d ago

dataflow 12d ago

It's not clear such a thing even exists in general though. It's certainly not guaranteed by packages. What would that be for numba?

rtpg 12d ago
Yep it's not clear, and a bit of a case-by-case thing. Fortunately most codebases only need to do this in a handful of spots so you can really "just" look at a package and find a file that probably is safe. For example, numba._version only imports standard library stuff so is probably good enough here[0] It would be nice to have general querying capabilities here, of course. I just think that in practice there's at least a halfway-decent workaround in almost any real situation [0] https://github.com/numba/numba/blob/main/numba/_version.py https://github.com/numba/numba/blob/main/numba/_version.py

zbentley 12d ago

Common? Yes. Canonical/ideal? No. Optional dependency specifiers in your package metadata is a much better way to go. You can use those even if you don't publish your package as an artifact; `pip install -e .[optional-thing]` should work, or can be made to, easily.

rtpg 12d ago
That's only part of the puzzle. Your program needs to branch on whether the dependency is installed or not! "Oh you don't have optional dependency? Then do X" needs to happen at runtime right?
- zbentley 9d ago
  I explained further here: https://news.ycombinator.com/item?id=49604462 https://news.ycombinator.com/item?id=49604462 In my preference order: an explicit CLI option/envvar which requires the optional dep, a flag file on the filesystem, or an ImportError attempt if you absolutely must. Use a stub/trampoline file in the conditionals so that static analyzers and laziness analysis on that file itself still work.