-
-
Notifications
You must be signed in to change notification settings - Fork 71
Expand file tree
/
Copy pathpyproject.toml
More file actions
789 lines (699 loc) · 37.3 KB
/
pyproject.toml
File metadata and controls
789 lines (699 loc) · 37.3 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
# --------------------( LICENSE )--------------------
# Copyright (c) 2014-2026 Beartype authors.
# See "LICENSE" for further details.
#
# --------------------( SYNOPSIS )--------------------
# Packager-agnostic package build configuration. Unlike obsolete package build
# configuration formats (e.g., "setup.py", "MANIFEST.in") unique to a subset of
# third-party package management devtools (e.g., "pip", "setuptools"), this file
# conforms to official standards (e.g., PEPs 517, 518, 621) and hence
# generically supports *ALL* such devtools.
#
# Say goodbye to project distribution hell, where only twenty distinct files in
# twenty distinct formats suffice to distribute a single project.
#
# --------------------( USAGE )--------------------
# Common Hatch commands include:
#
# # Validate this file. *ALWAYS* run this command after modifying this file.
# $ hatch project metadata | less
#
# # Build both a source (tarball) *AND* binary distribution (wheel).
# $ hatch build -t sdist -t wheel
#
# --------------------( SEE ALSO )--------------------
# * https://snarky.ca/clarifying-pep-518
# "Clarifying PEP 518 (a.k.a. pyproject.toml)", a human-readable article from
# one of the principal authors of the "pyproject.toml" standard.
# ....................{ PEP 621 }....................
# PEP 621-compliant section generically defining project metadata in a build
# tool-agnostic manner.
[project]
# Fully-qualified name of this project's top-level Python package.
name = "beartype"
# Human-readable single-line synopsis of this project.
#
# Note that, by PyPI design, this string *MUST* prefix each newline in this
# string with a continuation character (which then forces line wrapping) but
# otherwise not span multiple lines or paragraphs.
#
# See also official TOML documentation on multi-line strings: https://toml.io
description = """\
Unbearably fast near-real-time pure-Python runtime-static type-checker.\
"""
# Relative filename of the top-level file describing project licensing.
#
# Note that PEP 621 prohibits this table (i.e., dictionary) from defining both
# the "file" and "text" keys (e.g., 'text = "MIT"'). While defining both would
# certainly be preferable, the "file" key takes precedence over the "text" key.
license = { file = "LICENSE" }
# Relative filename of the top-level file describing this project. Read it and
# then weep as your eyes bleed! \o/
readme = "README.rst"
# List of all lowercase alphabetic keywords synopsising this project.
#
# These keywords may be arbitrarily selected so as to pretend to improve search
# engine optimization (SEO). In actuality, they do absolutely nothing.
keywords = [
"python",
"annotations",
"type checking",
"type hints",
]
# List of all PyPI-specific trove classifier strings synopsizing this project.
# Each such string *MUST* contain either two or three " :: " substrings
# delimiting human-readable capitalized English words formally recognized by the
# "distutils"-specific register() command. See also:
# * https://pypi.org/classifiers
# Plaintext list of all trove classifier strings recognized by PyPI.
classifiers = [
# PyPI-specific version type. The number specified here is a magic constant
# with no relation to this package's version numbering scheme. *sigh*
"Development Status :: 5 - Production/Stable",
# Miscellaneous metadata.
"Intended Audience :: Developers",
"License :: OSI Approved :: MIT License",
"Natural Language :: English",
"Operating System :: OS Independent",
"Programming Language :: Python :: 3",
"Programming Language :: Python :: 3 :: Only",
"Topic :: Software Development :: Code Generators",
"Topic :: Software Development :: Libraries :: Python Modules",
"Topic :: Software Development :: Quality Assurance",
"Typing :: Typed",
]
# List of all principal authors of this package as a list of tables (i.e.,
# dictionaries) defining both the names and e-mail addresses of these authors.
#
# These authors should be thought of as the corresponding authors of a paper.
# Ideally, correspondence should be redirected to these authors.
authors = [
]
# List of all secondary authors of this package as a list of tables (i.e.,
# dictionaries) defining both the names and e-mail addresses of these authors.
#
# These authors significantly contributed to the development of this project,
# but lack the "expertise" [read: "they're too smart for this"] to respond to
# external inquiries. Ideally, correspondence should *NOT* be redirected to
# these authors.
# maintainers = [
# { name="Cecil Curry", email="[email protected]" }, # <-- it's me all the way down, huh?
# ]
# List of the names of all "[project]" fields to be resolved dynamically through
# build toolchain-specific plugins (rather than defined statically above).
dynamic = [
# Dynamically resolve the "[project]" "version" field via the Hatch-specific
# "[tool.hatch.version]" subsection, subsequently defined below.
"version",
]
# ....................{ PEP 621 ~ dependencies }....................
#!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
# WARNING: Changes to this Python interpreter version specifier *MUST* be
# synchronized with:
# * Continuous integration (CI) test matrices, including:
# * The top-level "tox.ini" file.
# * The "jobs/tests/strategy/matrix/{tox-env,include/python-version}"
# settings of the GitHub Actions-specific
# ".github/workflows/python_test.yml" file.
# * Integration test data, including:
# * The "beartype_test/a90_func/data/external/poetry/pyproject.toml" file.
# * Front-facing documentation (e.g., "doc/src/pep.rst").
# * Signs declared by the private "beartype._data.hint.pep.datapepsign"
# submodule, which *MUST* be synchronized against the "__all__" dunder list
# global of the "typing" module bundled with the most recent CPython release.
#!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
# WARNING: Downstream consumers leveraging Poetry effectively require this
# version to be *SIMPLE* rather than *VERBOSE*. Why? Because Poetry enforces
# transitive Python interpreter version constraints. Previously, we attempted to
# require exact versions by blacklisting problematic Python release candidates
# known to be incompatible with beartype: e.g.,
# requires-python = ">=3.10,!=3.14.0rc1,!=3.14.0rc2"
#
# Technically, doing so resolved problematic incompatibilities with users.
# Pragmatically, doing so also then required *EVERY* Poetry user to adopt the
# same requirement string in their own "pyproject.toml" files -- even though
# literally no one cared about those problematic Python release candidates at
# that point, because the next stable Python release had already been published.
# Poetry greeted users failing to do so with crazy walls of text beginning with:
# The current project's supported Python range (>=3.10) is not compatible
# with some of the required packages Python requirement:
# - beartype requires Python !=3.14.0rc1,!=3.14.0rc2,>=3.10, so it will
# not be installable for Python 3.14.0rc1 || 3.14.0rc2
#
# To prevent beartype requirements from polluting the entire Python ecosystem,
# simple version requirements are strongly preferable.
#!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
# Minimum Python interpreter version required by this package.
#
# As a tradeoff between backward compatibility, security, and maintainability,
# this package strongly attempts to preserve compatibility with the first stable
# release of the oldest version of CPython still under active development.
# Obsolete and insecure versions of CPython that have reached their official End
# of Life (EoL) (e.g., Python 3.7) are explicitly unsupported.
#
# Note that:
# * This requirement specification intentionally blacklists obsolete Python 3.14
# release candidates, which removed the PEP 484-compliant "typing.ByteString"
# type hint singleton added back by Python 3.14 release candidate 3. Older
# release candidates are non-compliant with the official Python 3.14 release
# and thus @beartype itself. See also:
# https://github.com/beartype/beartype/issues/561#issuecomment-3379278748
requires-python = ">=3.10"
# Mandatory runtime dependencies. This package intentionally requires no
# mandatory runtime dependencies and hopefully never will.
dependencies = []
# ....................{ PEP 621 ~ dependencies : optional }....................
# Optional dependencies specified as a set of zero or more assignments of the
# form "{extra_name} = [{extra_dependency_1}, ...]", where:
# * "{extra_name}" is the arbitrary name of a project-specific "extra" (i.e.,
# category of optional dependencies).
# * "{{extra_dependency_1}, ..." is a comma-delimited list of optional
# dependencies installed under this "extra".
#
# When installing this project with "pip", users may additionally install these
# optional dependencies by subscripting the name of this project by these
# extras in comma-delimited fashion: e.g.,
# $ pip install beartype[doc-rtd,test-tox]
#
# Note that PEP 621 explicitly supports dependency composition through
# self-referential "extras". See also this awesome StackOverflow answer:
# https://stackoverflow.com/a/72524073/2809027
[project.optional-dependencies]
#FIXME: Most of these "extras" should be transformed into PEP 735-compliant
#"[dependency-groups]" instead. Since the current approach "just works," we
#can't really be bothered to do the right thing at the moment. See also:
# https://peps.python.org/pep-0735
# GitHub Pages (GHP)-specific documentation-time package dependencies required
# to automatically build documentation for this project from GitHub's homegrown
# hosting service.
doc-ghp = [
# ....................{ THEME }....................
# Theme stack -- which transitively requires reasonably recent versions of
# both MkDocs itself as well as all requisite MkDocs plugins. Note that:
# * The "imaging" extra is required by popular optional "mkdocs-material"
# plugins (e.g., "optimize", "social"). Doing so installs Python-centric
# image-processing packages like CairoSVG and Pillow, which *COULD* prove
# non-trivial to install under edge-case environments and platforms.
"mkdocs-material[imaging] >=9.6.0",
# ....................{ EXTENSIONS }....................
# API reference generation stack -- which transitively requires a reasonably
# recent version of the third-party "mkdocstrings" extension as well.
"mkdocstrings-python >=1.16.0",
# "mkdocstrings-python"-specific third-party extension expanding the default
# "mkdocstrings-python" support for absolute cross-references with
# additional support for relative cross-references.
"mkdocstrings-python-xref >=1.16.0",
]
#FIXME: Remove *AFTER* successfully migrating from RTD to GHP.
# Read The Docs (RTD)-specific documentation-time package dependencies required
# to automatically build documentation for this project from the third-party RTD
# hosting service. For consistency, these dependencies are often constrained to
# build documentation with a single well-tested configuration.
doc-rtd = [
#FIXME: Relax the maximum Sphinx version restriction (e.g., by simply
#removing the restriction on "<6.0.0").
# Sphinx itself. Specifically, this project requires:
# * sphinx >= 4.2.0, which resolved a severe compatibility issue under
# Python >= 3.10. See also this upstream issue:
# https://github.com/sphinx-doc/sphinx/issues/9816
# * sphinx < 6.0.0, as more recent versions currently conflict with our
# Sphinx theme. See again the same upstream issue as above.
"sphinx >=4.2.0,<6.0.0",
#FIXME: Switch! So, "pydata-sphinx-theme" is ostensibly *MOSTLY* great.
#However, there are numerous obvious eccentricities in "pydata-sphinx-theme"
#that we strongly disagree with -- especially that theme's oddball division
#in TOC heading levels between the top and left sidebars.
#
#Enter "sphinx-book-theme", stage left. "sphinx-book-theme" is based on
#"pydata-sphinx-theme", but entirely dispenses with all of the obvious
#eccentricities that hamper usage of "pydata-sphinx-theme". We no longer
#have adequate time to maintain custom documentation CSS against the moving
#target that is "pydata-sphinx-theme". Ergo, we should instead let
#"sphinx-book-theme" do all of that heavy lifting for us. Doing so will
#enable us to:
#* Lift the horrifying constraint above on a maximum Sphinx version. *gulp*
#* Substantially simplify our Sphinx configuration. Notably, the entire
# fragile "doc/src/_templates/" subdirectory should be *ENTIRELY* excised
# away.
#
#Please transition to "sphinx-book-theme" as time permits.
# Third-party Sphinx theme (i.e., extension providing the custom HTML theme
# preferred by this documentation). This theme was selected according to
# mostly objective (albeit ultimately subjective) heuristic criteria. In
# descending order of importance, we selected the theme with:
#
# 1. The most frequent git commit history.
# 2. The open issues and pull requests (PRs).
# 3. The most GitHub stars as a crude proxy for aggregate rating.
# 4. **IS NOT STRONGLY OPINIONATED** (i.e., is configurable with standard
# Sphinx settings and directives).
#
# Furo
# ----
# Furo handily bested all other themes across the first three criteria. Furo
# is very well-maintained, frequently closes out open issues and merges open
# PRs, and sports the highest quantity of GitHub stars by an overwhelming
# margin. Sadly, Furo handily loses against literally unmaintained themes
# across the final criteria. Furo is absurdly strongly opinionated to an
# authoritarian degree we rarely find in open-source software. Why? Because
# it's principal maintainer is. Like maintainer, like software. Furo
# routinely ignores standard Sphinx settings and directives due to
# subjective opinions held by its maintainer, including:
#
# * Most user-defined ":toctree:" settings used to configure both global and
# local tables of contents (TOCs) and thus the leftmost navigation
# sidebar, effectively preventing users from using that sidebar to
# navigate to anything. We are *NOT* kidding. ":toctree:" settings
# ignored by Furo include:
#
# * ":maxdepth:". Internally, Furo forces the ":titlesonly:" setting by
# passing "titles_only=True" to Sphinx's "toctree()" function at
# runtime. Doing so effectively coerces ":maxdepth: 1", thus
# intentionally hiding *all* document structure from the navigation
# sidebar -- where (usually) *all* document structure is displayed.
# Users thus have no means of directly jumping from the root landing
# page to child leaf documents, significantly obstructing user
# experience (UX) and usability. See also this feature request
# discussion to relax these constraints:
# https://github.com/pradyunsg/furo/discussions/146
#
# ...to which the Furo maintainer caustically replied:
#
# No, there isn't any (supported) way to do this.
#
# Separating the page content hierarchy and site structure was an
# explicit design goal.
#
# We fundamentally disagree with those goals and thus permanently switched
# away from Furo. Unjustified opinions are the little death of sanity.
#
# PyData
# ------
# Furo and PyData are neck-and-neck with respect to git commit history; both
# are extremely well-maintained. Furo leaps ahead with respect to both issue
# and PR resolution, however; PyData has an extreme number of open issues
# and PRs, where Furo enjoys none. Moreover, Furo also enjoys dramatically
# more GitHub stars.
#
# Nonetheless, PyData is *NOT* strongly opinionated; Furo is. PyData does
# *not* silently ignore standard Sphinx settings and directives for largely
# indefensible reasons. Consequently, PyData wins by default. In fact, *ANY*
# other theme (including even unmaintained dead themes) wins by default;
# *NO* other theme (to my limited knowledge) forcefully ignores standard
# Sphinx settings and directives to the extent that Furo does.
#
# PyData wins by literally doing nothing. Laziness prevails. All hail
# La-Z-Boy.
"pydata-sphinx-theme <=0.7.2",
# The older version of "pydata-sphinx-theme" currently required above to
# build this documentation assumes that Python bundles the "distutils"
# package, which Python >= 3.12 no longer does. Instead, explicitly install
# the third-party "setuptools" toolchain, which implicitly installs
# "distutils" as well... via a horribly antiquated hack. Just do it. \o/
"setuptools",
# Third-party Sphinx extensions.
"autoapi >=0.9.0",
"sphinxext-opengraph >=0.7.5",
]
# Tox-specific test-time dependencies required to test this package via
# the third-party "tox" command at the command line.
#
# Note that:
# * The "extras" key of the top-level "tox.ini" file explicitly references this
# extra.
# * Failure to list *ALL* optional test-time dependencies here commonly results
# in errors from mypy, which raises false positives on parsing import
# statements for uninstalled third-party packages (e.g., "import numpy").
test-tox = [
#!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
# CAUTION: Avoid constraining optional test-time dependencies to version
# ranges, which commonly fail for edge-case test environments -- including:
# * The oldest Python version still supported by @beartype, which typically
# is *NOT* supported by newer versions of these dependencies.
#!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
# ....................{ CORE }....................
# A relatively modern version of "pytest" is required. It's old by now. I
# feel depressed just reading comments like this. Dismantled, this is:
# * "pytest 6.2.0" first publicized the "pytest.MonkeyPatch" object, which
# previously was *ONLY* accessible via the "monkeypatch" fixture. Now,
# this object is conveniently directly importable.
"pytest >=6.2.0",
# ....................{ BUILD }....................
# Build-centric optional test-time dependencies.
# Required by optional Poetry-specific integration tests.
"poetry",
# ....................{ DOCUMENTATION }....................
# Documentation-centric optional test-time dependencies.
# Required by optional Docutils-specific integration tests. Dismantled, this
# is:
# * "docutils 0.22.0" deprecated the "writer_name" parameter accepted by the
# docutils.core.publish_parts() function.
"docutils >=0.22.0",
# Required by optional Sphinx-specific integration tests.
"sphinx",
# ....................{ DOOR }....................
# DOOR-specific optional test-time dependencies required to exercise all
# possible edge cases of the "beartype.door" subpackage.
# Required by optional beartype.door.infer_hint()-specific unit tests.
"pygments",
# ....................{ ETC }....................
# Miscellaneous optional test-time dependencies.
#FIXME: Reenable Python >= 3.15 support *AFTER* nuitka and all reverse
#dependencies thereof officially ship Python 3.14 wheels.
# Required by optional nuitka-specific integration tests if the current
# platform is a Linux distribution.
"nuitka >=1.2.6; sys_platform == 'linux' and python_version < '3.15.0'",
# ....................{ CLI }....................
# Required by optional Typer-specific integration tests.
"typer",
# ....................{ CLI ~ click }....................
# Required by optional Click-specific integration tests.
"click",
"rich-click",
# Required by optional Celery-specific integration tests. Note that Celery
# requires Click.
"celery",
# ....................{ CLI ~ exe }....................
# Required by optional PyInstaller-specific integration tests.
"pyinstaller",
# ....................{ DATABASE }....................
# Required by optional Redis-specific integration tests.
"redis",
# Required by optional SQLAlchemy-specific integration tests.
"sqlalchemy",
# ....................{ SCIENCE ~ data }....................
# Data science-centric optional test-time dependencies.
#FIXME: Reenable Python >= 3.15 support *AFTER* Numba supports Python 3.15.
# Required by optional numba-specific integration tests.
"numba; python_version < '3.15.0'",
# ....................{ SCIENCE ~ data : ml }....................
# Machine learning-centric optional test-time dependencies. These
# dependencies are well-known to be extremely non-trivial to install,
# typically due to conditionally depending on low-level C(++)-driven
# hardware GPU and TPU compute APIs (e.g., Nvidia CUDA, AMD OpenCL). To
# improve the likelihood of success on both local and remote workflows,
# these dependencies are intentionally confined to Linux.
#FIXME: Reenable Python >= 3.15 support *AFTER* PyTorch supports Python
#3.14.
# Required by optional PyTorch-specific integration tests if the current
# platform is a Linux distribution.
"torch; sys_platform == 'linux' and python_version < '3.15.0'",
# ....................{ SCIENCE ~ data : ml : jax }....................
# JAX-specific optional test-time dependencies.
#FIXME: Reenable Python >= 3.15 support *AFTER* JAX is readily installable
#under Python 3.15. JAX requires so many mandatory dependencies that this
#may take some time indeed. For example, JAX transitively requires SciPy,
#which currently fails to ship Python 3.15 wheels and, moreover, is not even
#readily buildable under my local Arch machine that can build anything.
# Required by optional JAX-specific integration tests and JAX-dependent
# packages (e.g., Equinox) if the current platform is a Linux distribution.
#
# Note that JAX *MUST* be installed with one or more subscripted extras.
# Omitting extras installs only the high-level pure-Python "jax" package
# *WITHOUT* also installing a low-level hardware-specific variant of the
# typically C-based "jaxlib" package, which results in the "jax" package
# being unimportable and thus non-working. Listing the "cpu" extra also
# installs a low-level CPU-specific variant of the C-based "jaxlib" package.
# Since GitHub Actions-based continuous integration (CI) workflows are
# unlikely to reliably provide GPU or TPU compute hardware or APIs, the only
# safe and reliable alternative is CPU-specific.
"jax[cpu]; sys_platform == 'linux' and python_version < '3.15.0'",
# Required by optional JAX- and Equinox-specific integration tests.
"jaxtyping; sys_platform == 'linux'",
#FIXME: Reenable Python >= 3.15 support *AFTER* JAX is readily installable
#under Python 3.15. See above for further commentary.
# Required by optional Equinox-specific integration tests. Note that Equinox
# requires JAX.
"equinox; sys_platform == 'linux' and python_version < '3.15.0'",
# ....................{ SCIENCE ~ data : ml : numpy }....................
# NumPy-specific optional test-time dependencies.
#FIXME: Reenable Python >= 3.15 support *AFTER* NumPy supports Python 3.15.
#FIXME: Consider dropping the 'and platform_python_implementation != "PyPy"'
#clause now that "tox.ini" installs NumPy wheels from a third-party vendor
#explicitly supporting PyPy.
# Require NumPy. NumPy has become *EXTREMELY* non-trivial to install under
# macOS with "pip", due to the conjunction of multiple issues. These
# include:
# * NumPy > 1.18.0, whose initial importation now implicitly detects
# whether the BLAS implementation NumPy was linked against is sane and
# raises a "RuntimeError" exception if that implementation is insane:
# RuntimeError: Polyfit sanity test emitted a warning, most
# likely due to using a buggy Accelerate backend. If you
# compiled yourself, more information is available at
# https://numpy.org/doc/stable/user/building.html#accelerated-blas-lapack-libraries
# Otherwise report this to the vendor that provided NumPy.
# RankWarning: Polyfit may be poorly conditioned
# * Apple's blatantly broken multithreaded implementation of their
# "Accelerate" BLAS replacement, which neither NumPy nor "pip" have *ANY*
# semblance of control over.
# * "pip" under PyPy, which for unknown reasons fails to properly install
# NumPy even when the "--force-reinstall" option is explicitly passed to
# "pip". Oddly, passing that option to "pip" under CPython resolves this
# issue -- which is why we only selectively disable NumPy installation
# under macOS + PyPy.
#
# See also this upstream NumPy issue:
# https://github.com/numpy/numpy/issues/15947
"""numpy; \
python_version < '3.15.0' and \
sys_platform != 'darwin' and \
platform_python_implementation != 'PyPy'\
""",
#FIXME: Reenable Python >= 3.15 support *AFTER* explicitly supported.
#See above for further commentary.
# Required by optional LangChain-specific integration tests. Note that
# LangChain requires both NumPy and Pydantic.
"""langchain; \
python_version < '3.15.0' and \
sys_platform != 'darwin' and \
platform_python_implementation != 'PyPy'\
""",
# ....................{ SCIENCE ~ data : ml : dataframe}....................
# DataFrame (e.g., Pandas, Polars)-specific optional test-time dependencies.
#FIXME: Reenable Python >= 3.15 support *AFTER* explicitly supported.
# Required by optional Pandera-specific integration tests. Note that:
# * Pandera requires Pydantic and Pandas.
# * The @beartype test suite requires pandera >= 0.26.0. Prior pandera
# versions were Pandas-specific. Modern pandera versions are API-agnostic
# and now support a wide variety of DataFrame-like APIs, including Polars.
"pandera >= 0.26.0; python_version < '3.15.0'",
#FIXME: Reenable Python >= 3.15 support *AFTER* explicitly supported.
# Required by optional Pandera- and Polars-specific integration tests.
"polars; python_version < '3.15.0'",
#FIXME: Reenable Python >= 3.15 support *AFTER* explicitly supported
# Required by optional xarray-specific integration tests. Note that xarray
# requires Pandas.
"xarray; python_version < '3.15.0'",
# ....................{ SCIENCE ~ data : ml : pydantic }....................
# Pydantic-specific optional test-time dependencies.
#FIXME: Reenable Python >= 3.15 support *AFTER* explicitly supported.
# Required by optional FastMCP-specific integration tests. Note that FastMCP
# requires Pydantic.
"fastmcp; python_version < '3.15.0'",
#FIXME: Actually, let's *NOT* install "pyarrow". "pyarrow" is super-intense,
#because Apache Arrow is super-intense. Since nothing in @beartype requires
#"pyarrow", let's tamp down on all this bare-knuckle intensity for now.
# Required by optional pandera-specific integration tests. Technically,
# "pyarrow" is an optional runtime dependency of pandera that appears to now
# be effectively mandatory under modern versions of pandera. If "pyarrow" is
# *NOT* installed, pandera raises exceptions from the @beartype test suite
# despite tests neither referencing nor requiring "pyarrow"-specific dtypes
# resembling:
# TypeError: pyarrow must be installed to use pyarrow dtypes.
# "pyarrow",
# ....................{ TYPING }....................
# Typing-centric optional test-time dependencies.
# Require a reasonably recent version of mypy known to behave well. Less
# recent versions are significantly deficient with respect to error
# reporting and *MUST* thus be blacklisted.
#
# Note that PyPy currently fails to support mypy. See also this official
# documentation discussing this regrettable incompatibility:
# https://mypy.readthedocs.io/en/stable/faq.html#does-it-run-on-pypy
"mypy >=0.800; platform_python_implementation != 'PyPy'",
# Require a reasonably recent version of pyright known to behave well. Less
# recent versions are significantly deficient with respect to error
# reporting and *MUST* thus be blacklisted. However, note that:
# * Multiple versions of 1.1.365 < pyright < 1.1.370 fail to terminate on
# the @beartype codebase. Thankfully, @erictraut of @microsoft fame
# exhibited heroic strength by:
# * Rapidly resolving the issue.
# * Integrating @beartype into @hauntsaninja's open-source "mypy_primer"
# toolchain, preventing regressions in multiple static type-checkers
# (including pyright) by exercising those type-checkers against multiple
# open-source third-party packages (including @beartype). In other
# words, this should *PROBABLY* never happen again.
# * Publishing pyright 1.1.370 with that resolution.
#
# @beartype salutes both @erictraut and @hauntsaninja. Their legend grows
# with each passing commit.
"pyright >=1.1.370",
# Required to exercise third-party backports of type hint factories
# published by the standard "typing" module under newer versions of Python.
# Dismantled, this is:
# * "typing-extensions >=3.10.0.0", which backports *ALL* "typing"
# attributes unavailable under older Python interpreters supported by the
# @beartype decorator.
'typing-extensions >=3.10.0.0',
]
# Tox-specific test-time coverage dependencies required to measure test coverage
# for this package.
#
# Note that the "extras" key of the top-level "tox.ini" file explicitly
# references this extra.
test-tox-coverage = [
"coverage >=5.5",
]
# Developer-specific test-time dependencies required to test this package via
# the third-party "pytest" and "tox" commands at the command line.
test = [
# Tox-specific test-time dependencies.
"beartype[test-tox,test-tox-coverage]",
# A relatively modern version of "tox" is required. It's quite old by now. I
# feel depressed just reading comments like this...
'tox >=3.20.1',
]
# Developer-specific dependencies required to develop and contribute pull
# requests (PRs) for this project. Notably, this includes *ALL* test- and
# documentation-time dependencies.
dev = ["beartype[doc-rtd,test]"]
# ....................{ PEP 621 ~ urls }....................
# Table (i.e., dictionary) mapping from the PyPI-recognized name of each
# relevant project URL to that URL.
[project.urls]
Docs = "https://beartype.readthedocs.io"
GitHub = "https://github.com/beartype/beartype"
Forums = "https://github.com/beartype/beartype/discussions"
Issues = "https://github.com/beartype/beartype/issues"
Releases = "https://github.com/beartype/beartype/releases"
# ....................{ PEP 517 }....................
# PEP 517-compliant section declaring the third-party build tools required to
# install this "pyproject.toml"-based project.
[build-system]
# List of all third-party Python packages required to build (i.e., install) this
# project from both codebase tarballs and binary wheels.
requires = ["hatchling >=1.14.0"]
# Fully-qualified name of the Python submodule of a third-party Python package
# listed above to be imported at runtime by third-party Python package managers
# (e.g., "pip") to build this project.
build-backend = "hatchling.build"
# ....................{ NON-PEP ~ hatch }....................
# PEP-noncompliant section declaring Hatch-specific version settings. See also:
# * Official documentation for this section.
# https://hatch.pypa.io/latest/version
[tool.hatch.version]
# Relative filename of the Python submodule defining either a PEP 8-compliant
# "__version__" dunder global *OR* a PEP-noncompliant "VERSION" global, which
# Hatch then statically parses to obtain the current version of this project.
path = "beartype/meta.py"
# ....................{ NON-PEP ~ hatch : path }....................
# PEP-noncompliant section declaring Hatch-specific build settings. Note that:
# * Hatch silently ignores *ALL* pathnames matched by ".gitignore" files
# distributed throughout this codebase.
[tool.hatch.build]
# PEP-noncompliant section declaring Hatch-specific build settings when
# building binary distributions (e.g., wheels).
[tool.hatch.build.targets.wheel]
# Whitelist of one or more Bash-style glob expressions matching the relative
# pathnames of all paths to be included in binary distributions (e.g., wheels)
# but *NOT* source distributions (e.g., tarballs) created by Hatch.
include = [
#!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
# CAUTION: Synchronize with glob expressions for source distributions below.
#!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
# Glob expression recursively matching *ALL* Python submodules in this
# project's package directory.
"/beartype/**/*.py",
# Relative filenames of all requisite package-level installation-time files.
"/beartype/py.typed",
]
# PEP-noncompliant section declaring Hatch-specific build settings when
# building source distributions (e.g., tarballs).
[tool.hatch.build.targets.sdist]
# Whitelist of one or more Bash-style glob expressions matching the relative
# pathnames of all paths to be included in source distributions (e.g., tarballs)
# but *NOT* binary distributions (e.g., wheels) created by Hatch.
#
# Note that:
# * This setting is the Hatch-specific equivalent of the setuptools-specific
# "MANIFEST.in" file, which serves a similar (albeit non-standard, poorly
# documented, and obfuscatory) purpose in the setuptools community.
# * Hatch *ALWAYS* implicitly includes at least these files in source
# distributions:
# * ".gitignore".
# * "AUTHORS".
# * "LICENSE".
# * "README*".
# * "pyproject.toml".
#
# Nonetheless, explicit is better than implicit. Trusting all future versions of
# Hatch to preserve this contract is a bridge too far for us. Ergo, we
# explicitly match *ALL* paths to be included in source distributions here.
include = [
# Relative basenames of all requisite files residing in *ANY* directory.
".gitignore",
# Relative basenames of all requisite top-level installation-time files.
"/LICENSE",
"/*.md",
"/*.rst",
"/conftest.py",
"/mkdocs",
"/mypy",
"/mypy.ini",
"/pyproject.toml",
"/pyright",
"/pytest",
"/pytest.ini",
"/sphinx",
"/tox",
"/tox.ini",
"/.codecov.yml",
"/.coveragerc",
"/.readthedocs.yaml",
# Relative dirnames of all requisite top-level installation-time
# directories, including:
# * All up-to-date MkDocs-specific files documenting this project in the
# top-level "docs/" subdirectory.
# * All obsolete Sphinx-specific files documenting this project in the
# top-level "doc/" subdirectory.
#
# Yes, this is confusing. The obsolete "doc/" subdirectory will be
# permanently removed at some point. For now, it lingers like a bad smell.
"/docs/*.md",
"/docs/js/*.js",
"/doc/Makefile",
"/doc/*.bat",
"/doc/*.md",
"/doc/*.rst",
"/doc/src",
# Glob expression recursively matching *ALL* Python submodules in this
# project's test suite.
"/beartype_test/**/*.py",
#!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
# CAUTION: Synchronize with glob expressions for binary distributions above.
#!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
# Glob expression recursively matching *ALL* Python submodules in this
# project's package directory.
"/beartype/**/*.py",
# Relative filenames of all requisite package-level installation-time files.
"/beartype/py.typed",
]
# ....................{ NON-PEP ~ pyright }....................
# PEP-noncompliant section declaring pyright-specific settings. See also:
# * Official documentation for this section.
# https://github.com/microsoft/pyright/blob/main/docs/configuration.md
[tool.pyright]
# List of POSIX-compatible glob expressions matching all paths to be statically
# type-checked by pyright.
include = ["beartype"]
# List of POSIX-compatible glob expressions matching all paths to *NOT* be
# statically type-checked by pyright.
exclude = ["**/__pycache__"]
# No idea, honestly. pyright appears to want this. It is what it is. 8<>
stubPath = ""
# Instruct pyright to statically type-check Python Enhancement Proposals (PEPs)
# that have been accepted for standard inclusion with the next major stable
# release of Python but *NOT* any existing release of Python. Examples include:
# * PEP 747-compliant "typing.TypeForm[...]" type hints under Python >= 3.14.
enableExperimentalFeatures = true