new package manager for Bear #243
Replies: 5 comments 1 reply
-
Yes! Gods, yes! So much "Yes!" Pull up a hand-crafted Canadian Muskoka chair as Grandpa @leycec rants incoherently until his dentures fall out. 👴
Let Me Sing the Many Praises of HatchHatch is so much win. I cannot stand Hatch, on the other hand, just works. I'm incredibly impressed. After years of self-flagellating myself with unsound Lest We Forget the Other GuysI briefly considered Flit and PDM as well. But... they're both third-party. I mean, sure. So is @beartype. But there's sorta no compelling alternative to @beartype. Flit and PDM, on the other hand, have stiff competition from Hatch, In short, I strongly suspect that everything except Hatch and Let Me Tell You What Now, PeepsClearly, @beartype's long-term packaging endgame is to abandon Laziness prevails. Thus, so do we. If at all possible, I'd prefer to quietly soldier on with Until then, however, the pain of transitioning @beartype away from For example, we really need to transition @beartype documentation from an obsolete to recent version of tl;dr@beartype is all about Hatch – just not quite yet. Let's let this simmer this Summer. See what I did there? It's a rhyme. I'll show myself out the door now. Oh... and thanks so much for this exciting discussion, @baggiponte! I see your good points and raise you laziness. |
Beta Was this translation helpful? Give feedback.
-
Excellent question. This may very well be the case! My particular boring use case (which bores me even as I type this) required bundling various non-Python files with Python packages as Praise be to Hatch, though. Hatch trivially supports this out-of-the-box via a very sensible
Excellent questions continue! Praise be to Hatch continues, too. Hatch fully complies with PEP 621. When you use Hatch, you trivially list dependencies in a tool-agnostic Most project's aren't crazy, however. In the case of an adjacent Python project I co-maintain with my wife called the BioElectric Tissue Simulation Engine (BETSE), this is a [project]
...
# List of all mandatory runtime dependencies.
dependencies = [
# Scientific stack. Dismantled, this is:
# * Numpy 1.13.0 first introduced the optional "axis" keyword argument to
# the numpy.unique() function, which this codebase commonly passes.
# * Pillow 5.3.0 first introduced the standard "pillow.__version__"
# attribute, which this codebase now expects to exist.
# * Matplotlib 3.6.0, which first deprecated various APIs and then
# introduced newer replacements for those APIs (e.g., the new
# "matplotlib.colormaps" subpackage).
"Numpy >=1.22.0",
"Pillow >=5.3.0",
"SciPy >=0.12.0",
"dill >=0.2.3",
"matplotlib >=3.6.0",
# IO stack. Dismantled, this is:
# * ruamel.yaml >= 0.15.24, which resolves a long-standing parser issue
# preventing complex YAML markup (e.g., ours) from being roundtripped:
# "0.15.24 (2017-08-09):
# * (finally) fixed longstanding issue 23 (reported by Antony Sottile),
# now handling comment between block mapping key and value correctly"
# * The new "ruamel.yaml" API first introduced in 0.15.0. While older
# versions strictly adhere to the functional PyYAML-compatible API, newer
# versions break backward compatibility by entirely supplanting that API
# with a modern object-oriented approach. Supporting both isn't worth the
# substantial increase in maintenance debt.
"ruamel.yaml >=0.15.24",
# QA stack. Dismantled, this is:
# * beartype >= 0.10.0, which first defined the "beartype.typing"
# compatibility layer widely used throughout this codebase.
"beartype >=0.10.0",
]
# ....................{ PEP 621 ~ dependencies : optional }....................
# List of all extras (i.e., settings with arbitrary names whose values are lists
# of optional dependencies, which external end user-oriented package managers
# like "pip" and "conda" then permit to be installed via those names).
[project.optional-dependencies]
# List of all optional runtime dependencies.
all = [
# A relatively modern version of NetworkX *EXCLUDING* 1.11, which critically
# broke backwards compatibility by coercing use of the unofficial inactive
# "pydotplus" PyDot fork rather than the official active "pydot" PyDot
# project, is directly required by this application. NetworkX >= 1.12
# reverted to supporting "pydot", thus warranting blacklisting of only
# NetworkX 1.11. (It is confusing, maybe? Yes!)
"networkx >=1.2",
"pydot >=1.0.28",
]
# List of all mandatory test-time dependencies.
test = [
# For simplicity, pytest should remain the only hard dependency for testing
# on local machines. While our testing regime optionally leverages
# third-party py.test plugins (e.g., "pytest-xdist"), these plugins are
# *NOT* required for simple testing.
#
# A relatively modern version of pytest is required. Specifically:
# * At least version 5.4.0 or newer, which refactored the previously
# defined private _pytest.capture.CaptureManager._getcapture() method
# into the newly defined private _pytest.capture._getmulticapture()
# function, which the "betse.lib.setuptools.command.supcmdtest" submodule
# necessarily monkey-patches at test time to sanitize captured output for
# long-running tests.
"pytest >=5.4.0",
# Mandatory test-time coverage package dependencies (i.e., dependencies
# required to measure test coverage for this package).
"coverage >=5.5",
]
# List of all mandatory documentation-time dependencies.
doc = ["sphinx"] This means that if you ever get tired of how awesome Hatch is and want to start self-flagellating yourself with a burlap sack called Flit, PDM, or
Wow! That's utterly fascinating. Thanks for the educational link. I have levelled up and am well on my way to graduating from Hatch University with a 2.70 GPA and extracurricular activities such as loitering on GitHub and spamming Reddit with @beartype propaganda. Good times. Technically, you could do what those Hatch docs suggest and define optional dependencies in a Hatch-specific Thus spake @leycec, who hopes to graduate from Hatch University with a 2.70 GPA.
Exactly. If it ain't broke, don't fix it. In my case, Thanks so much for the super-fun back and forth, @baggiponte. Futura sounds like a super-fun AI-oriented tech startup. As the Summer swells with heat, humidity, insects the size of your face, and my wife and I bicycling the back trails of Ontario, let's lead humanity to a bright future of friendly AI that does everything for us and demands only the energy from our mitochondria. Isn't that a small price to pay, in the end? |
Beta Was this translation helpful? Give feedback.
-
@leycec can I just say, you've somehow managed to find a yet another solution to yet another problem I've been facing for years now, and damn it, now I have to re-configure my whole toolchain again.
But hatch looks amazing. And I say this as someone that already obsessively looks for shiny new tools to solve every darn inconvenience I come across in my day-to-day. What can I say? I suppose I'm also a bit of a crazy community-standards lover (:sweat_smile: sweats in NIST) (Speaking of standards, I've somewhat unashamedly done the unthinkable and updated my user handle...apparently most things work, but aliasing handle-mentions inline was apparently too much of an ask for the GitHub Gods, so now there are loads of un-linked links in our issue discussion mentions. Sorry lol) |
Beta Was this translation helpful? Give feedback.
-
Dear @leycec, I know you said transitioning to hatch is not a priority but I'm still trying to do it to make things easier for you, hope you don't mind. For improving the code I had some propositions:
So what is your opinion on these propositions? Btw, I used beartype.claw in my codebase, it worked perfectly, find typing errors that typeguard didn't and solved a bug I was facing with typeguard concerning sphinx. Now I'm going to sleep (its 5AM for me), thank you for your amazing package! |
Beta Was this translation helpful? Give feedback.
-
Ho, ho, ho! It must be Christmas somewhere in the world, because I am chuckling like Santa while clutching my belly. There's a lot to unbox here. Let the unboxing begin.
Jubilation. I'm mindfully overjoyed that someone will be making my life and the lives of my users easier. It's happening. Also, my shoulders ache and I could use a deep-tissue massage. ...someone? ...anyone? So, that's a "maybe" then? 😩
Yes. So much yes.
Yes! So much yes! As for as I recall, Hatch currently only supports dynamic inspection of package versions and descriptions. That's fine, though. Here's what all of my other Hatch-driven Python packages do to dynamically synchronize versions: # In "pyproject.toml":
[project]
...
# List of the names of all settings recognized by this PEP 621-compliant section
# that the build backend (specified below) allows to be dynamically harvested
# from this project's top-level Python package. Supported settings include:
# * "version", which this build backend typically harvests from the PEP
# 8-compliant "{name}.__version__" dunder global.
# * "description", which this build backend typically harvests from the module
# docstring defined by the "{name}.__init__" submodule.
dynamic = ["version"]
# 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/__init__.py" # <-- or maybe "beartype/about.py"? *shrug shrug* I'm fine with breaking backward support by dropping Sphinx is the only concern, really. Our Gut
|
Beta Was this translation helpful? Give feedback.
-
Hi, I saw in your setup.py that you consider migrating to hatch. hatch is wonderful and I would totally respect that choice (I don't like poetry too). A consideration: I don't reckon PyPA recommending one package manager. As far as I remember reading around, their official position is not to endorse any package manager ATM.
One thing that hatch currently does not support is specifying dev dependencies (only optional dependencies). A package manager that is not poetry that does this is PDM - and is as feature-complete as poetry, without breaking PEPs. PDM is not affiliated under the PyPA. The tradeoff between hatch and PDM is that PDM does not create directory structures as hatch does (e.g.
hatch init
) nor allows using environments as hatch. I can't really tell whether PDM "supports dynamic retrieval of version specifiers from Python modules" as you write insetup.py
.Anyway, I'd be glad to help you with moving the package manager of your choice!
Beta Was this translation helpful? Give feedback.
All reactions