Vendor webassets code

[offbyone]

The webassets underlying code is showing signs of being abandoned. Per the discussion in miracle2k/webassets#553 with @justinmayer this PR vendors it into our plugin in the interim.

[offbyone]

Now we see how bad of a mess this build is in CI... expect at least one iteration

[offbyone]

Aight, this is good to merge. It ... may have sprawled a bit, because I could not wrangle poetry into giving me the dependencies that made sense, so I revamped the pyproject.toml too.

We should probably release this as 2.1

@justinmayer I still can't keep the release steps in my head; if you can do that, it'd be great (and maybe we should add them to the README for these various projects)

[offbyone]

Sorry, this one was a bit below my usual bar; I was distracted while I worked on it.

[justinmayer]

The Autopub-based release process involves including a RELEASE.md file in the PR, as documented here: https://docs.getpelican.com/en/latest/contribute.html#using-git-and-github

I made a comment about a change that I think will be necessary in order for the aforementioned release process to work, due to the fact that githubrelease still has not published a release containing a needed fix. (No longer relevant — see resolved follow-up comment below.)

Could you take a look at updating the Invoke tasks in tasks.py to account for the switch from Poetry to uv, Black/Flake8 to Ruff, etc.? The Cookiecutter plugin template is probably a good place to start: https://github.com/getpelican/cookiecutter-pelican-plugin/blob/main/%7B%7Bcookiecutter.repo_name%7D%7D/tasks.py

[offbyone]

How do you feel about the tasks assuming uv is installed? Trying to navigate the circular dependencies between making sure a venv exists and installing uv to create that venv is a bit ugly; if I can assume uv everything else gets very simple.

[offbyone]

A couple of notes

[justinmayer]

How do you feel about the tasks assuming uv is installed?

Feel free to use the tooling that you feel most comfortable with. Having not had a lot of time/opportunity to experiment with uv, I spent some time today trying to convert the https://github.com/autopub/test-github-ci project from Poetry to uv, and… it did not go well for me. I am accustomed to tools that will use a currently-activated virtual environment, but the uv folks seem steadfastly against supporting that workflow. They implemented a UV_PROJECT_ENVIRONMENT environment variable that tries to mitigate that shortcoming, but for my usual workflow, that did not make things any easier for me.

Even when I tried to stop going against the grain, I found it hard to understand how to install and use project dependencies. Running uv run pytest would result in error: Failed to spawn: pytest. Caused by: No such file or directory (os error 2), etc. The documentation did little to resolve that situation.

As seen in the https://github.com/getpelican/cookiecutter-pelican-plugin template, I have been using PDM with all the other plugins, and I've been very pleased with how it behaves. (In the end, I gave up on my uv experimentation and converted https://github.com/autopub/test-github-ci to be managed by PDM.) The other benefit to using a consistent set of tooling for Pelican plugins is that they can be kept up-to-date with upstream plugin template changes via Cruft (see https://github.com/getpelican/cookiecutter-pelican-plugin README for details on that).

But I digress. As I mentioned before, feel free to use the tooling that makes the most sense to you. Perhaps someday the paths of uv's development/docs and my workflow will converge 😉

[offbyone]

Nah, I'm fine to settle on a consistent one.

It's interesting; uv for me, anyway, does use the activated venv, but I might have other assumptions in my environment that don't match it. I'd rather keep template updating instead of slightly faster tools, as an ecosystem health thing, and I don't have the time or spare brain to figure out how to make a universal change work for everyone.

It's funny; our workflows are similar but with subtle differences; I've settled on justfiles and uv, instead of invoke and pdm, but the basic ideas are the same. Invoke isn't working out for me these days because it has to be in the virtualenv, which makes it non-ideal to set up the environment :D

Edit: I realize that my response was wandering enough it might not have been clear: all things being equal, or equal-ish, I would rather match the template than go my own way on this.

[justinmayer]

The uv folks seem to be quite insistent that they will not read $VIRTUAL_ENV for the purposes of uv add […], uv sync, etc:

• Allow customizing the project environment path with UV_PROJECT_ENVIRONMENT astral-sh/uv#6834
• In case VIRTUAL_ENV is different from .venv UV_PROJECT_ENVIRONMENT should be created automatically astral-sh/uv#7778

… and that behavior is consistent with my testing, in which the following warning is raised:

Warning: VIRTUAL_ENV=... does not match the project environment path .venv and will be ignored

I agree that particular Invoke limitation makes it less-than-ideal when bootstrapping.

Given the meandering path of Python packaging, I suppose we shouldn't be surprised to see so many tools with so much overlapping functionality and yet often quite different perspectives on how things should work. Software engineers are nothing if not opinionated! 😝

In any case, I agree that ecosystem consistency is often worth preserving. While the Pelican plugin template currently uses PDM, perhaps as uv matures it will someday find its way into the plugin template and then propagated to all the plugins via Cruft 😊

[offbyone]

Markdown requires python 3.9+, so I bumped this; I'll yank 3.8 out of CI

[offbyone]

And now I'm struggling to get pdm to install the dev dependencies: https://github.com/pelican-plugins/webassets/actions/runs/11647021032/job/32431789688?pr=16

😂

We can't win here :D

[justinmayer]

Many thanks for all your work on this, Chris! It seems it wasn't as easy as one would have hoped. Really appreciate all your efforts! 💕