migrate dependencies from Pipfile to uv / pyproject

[dckc]

Discovered uv via lobste.rs discussion. Looks cool.

I'm not really pushing the envelope, so stuff like deployment to netlify just works with a Pipfile that I've been using at least as far back as 2019, thru a python 2.7 -> 3.x transition.

But I've been concerned for some time that my dependencies are a little fragile (#14). Let's see how well uv handles them.

refs:

• blogging analysis paralysis: hakyll, hugo #14
• dependency constraints on flask etc. are too weak #217

[dckc]

Kerflewey

Why the heck is hatch complaining? Did I ask to use hatch somehow?

p.s. see discord discussion

$ uv run -- ./site serve
error: Failed to prepare distributions
  Caused by: Failed to fetch wheel: madmode-blog @ file:///home/connolly/projects/madmode-blog
  Caused by: Build backend failed to build wheel through `build_editable()` with exit status: 1
--- stdout:

--- stderr:
Traceback (most recent call last):
  File "<string>", line 11, in <module>
  File "/home/connolly/.cache/uv/builds-v0/.tmpRm3oOY/lib/python3.10/site-packages/hatchling/build.py", line 83, in build_editable
    return os.path.basename(next(builder.build(directory=wheel_directory, versions=['editable'])))
  File "/home/connolly/.cache/uv/builds-v0/.tmpRm3oOY/lib/python3.10/site-packages/hatchling/builders/plugin/interface.py", line 155, in build
    artifact = version_api[version](directory, **build_data)
  File "/home/connolly/.cache/uv/builds-v0/.tmpRm3oOY/lib/python3.10/site-packages/hatchling/builders/wheel.py", line 494, in build_editable
    return self.build_editable_detection(directory, **build_data)
  File "/home/connolly/.cache/uv/builds-v0/.tmpRm3oOY/lib/python3.10/site-packages/hatchling/builders/wheel.py", line 505, in build_editable_detection
    for included_file in self.recurse_selected_project_files():
  File "/home/connolly/.cache/uv/builds-v0/.tmpRm3oOY/lib/python3.10/site-packages/hatchling/builders/plugin/interface.py", line 180, in recurse_selected_project_files
    if self.config.only_include:
  File "/home/connolly/.cache/uv/builds-v0/.tmpRm3oOY/lib/python3.10/site-packages/hatchling/builders/config.py", line 806, in only_include
    only_include = only_include_config.get('only-include', self.default_only_include()) or self.packages
  File "/home/connolly/.cache/uv/builds-v0/.tmpRm3oOY/lib/python3.10/site-packages/hatchling/builders/wheel.py", line 260, in default_only_include
    return self.default_file_selection_options.only_include
  File "/usr/lib/python3.10/functools.py", line 981, in __get__
    val = self.func(instance)
  File "/home/connolly/.cache/uv/builds-v0/.tmpRm3oOY/lib/python3.10/site-packages/hatchling/builders/wheel.py", line 248, in default_file_selection_options
    raise ValueError(message)
ValueError: Unable to determine which files to ship inside the wheel using the following heuristics: https://hatch.pypa.io/latest/plugins/builder/wheel/#default-file-selection

The most likely cause of this is that there is no directory that matches the name of your project (madmode_blog).

At least one file selection option must be defined in the `tool.hatch.build.targets.wheel` table, see: https://hatch.pypa.io/latest/config/build/

As an example, if you intend to ship a directory named `foo` that resides within a `src` directory located at the root of your project, you can define the following:

[tool.hatch.build.targets.wheel]
packages = ["src/foo"]
---

for ref: 4fb8a09

[dckc]

vitual project still losing

Seems like progress, but...

$ uv run -- ./site serve
Traceback (most recent call last):
  File "/home/connolly/projects/madmode-blog/./site", line 20, in <module>
    from flaskext.markdown import Markdown
  File "/home/connolly/projects/madmode-blog/.venv/lib/python3.10/site-packages/flaskext/markdown.py", line 32, in <module>
    from flask import Markup
ImportError: cannot import name 'Markup' from 'flask' (/home/connolly/projects/madmode-blog/.venv/lib/python3.10/site-packages/flask/__init__.py)

p.s. another clue from discord

flask 2.* vs. 3.*

bluss: dckc the locked (pipenv) version of flask is 2.2.2, but with uv it's using flask 3.*, so there are breaking changes. it should hopefully work with equivalent versions

p.p.s.

• dependency constraints on flask etc. are too weak #217

[dckc]

uv tool is 34M - overkill? What is the goal here?

$ ls -sh ~/.local/bin/uv
34M /home/connolly/.local/bin/uv

Does explaining how to build my web site really merit 34M?

If I were having dependency solver performance issues, sure. But... I'm a long way from there.

requirements.txt hasn't gone away

What's the conventional wisdom? A "netlify frozen-flask" search turns up a Feb 2023 item that uses... pip install -r requirements.txt. They capture the constraints in a handful of lines:

Flask==2.2.3
Frozen-Flask==0.18
Markdown==3.4.1
pytest==7.2.1
pytest-cov==4.0.0
flake8==6.0.0

secure hash SBOM overkill?

Is there really any doubt what Flask==2.2.3 means?

If I were using fast-moving or leading edge stuff, a secure hash might make a lot of sense.
But I think I'm trying to avoid pushing the envelope when it comes to my blog.

how far behind is too far? e.g. python2

I doubted for the longest time that platforms would really stop supporting python2. But they did. It became painful to use.

I'd rather not migrate from flask 2 to flask 3, but I suppose I need to stay tuned in well enough to learn about semver-style breaking changes and to track the cost of migrating vs. staying put.

I do want to be able to take advantage of stuff like dependabot to address security issues.

netlify recommends Pipenv

The Python section of Manage build dependencies | Netlify Docs recommends Pipenv, along with a runtime.txt to manage the python version.

my Pipfile constraints are too weak

So the real issue here is: my Pipfile versions don't capture my compatibility constraints; they're all wildcards.

[dckc]

What does Nicolas use? Jekyll!

• Sep 1, 2019 Migrate to jekyll