Manage dependencies with uv

[bbc2]

This is just a suggestion (also because you seemed favorable in #139, and alternative proposal), because whoever publishes the new .apkg files may find this more or less easy depending on their experience with Python.

This does mainly two things:

• Use uv for dependency management (and virtualenv management for those who want it).
  • This is now a well-established tool in the Python ecosystem.
  • uv can do more (e.g. publish Python packages, manage script entry points) but we can limit our use to just dependency management.
• Remove the vendored genanki version (as a git submodule).
  • Since it has the sort_field_index in a released version, we no longer need a custom version.

I'm not a user of Conda but I suppose this removes it as an option for dependency management.

Note that with uv sync, you are guaranteed to get the same versions of packages as other contributors (thanks to uv.lock). There's probably a similar concept in Conda. To update the dependencies, you can update the pyproject.toml and/or do uv sync --upgrade. This could be a drawback if you don't like to require a git commit for dependency upgrades.

Hopefully this helps. Otherwise feel free to ignore. After all, there's not many dependencies to worry about here, so the situation is certainly manageable with whatever tool you're the most familiar with.

> uv tree
Resolved 7 packages in 0.69ms
anki-periodic-table-memory-pegs v0.1.0
├── genanki v0.13.1
│   ├── cached-property v2.0.1
│   ├── chevron v0.14.0
│   ├── frozendict v2.4.6
│   └── pyyaml v6.0.2
└── markdown2 v2.5.3

[remiberthoz]

Hi, thanks !

I will investigate this change a little more before proceeding. I am indeed favorable with directions simplifying the build system, even if I consider it quite simple already. It is simple assuming you have conda already, which I understand is not the case for everyone, and conda is not a light dependency.

I'm not a user of Conda but I suppose this removes it as an option for dependency management.

Yes !

Remove the vendored genanki version (as a git submodule).

I am however quite afraid of removing the pinned submodule version of genanki. Genanki has evolved a lot since many years. It is now an even better tool, but I would honestly not want to dig into updating the present repo to fit new API requirements for genanki. I will look into what's needed.

Note that with uv sync, you are guaranteed to get the same versions of packages as other contributors (thanks to uv.lock). There's probably a similar concept in Conda. To update the dependencies, you can update the pyproject.toml and/or do uv sync --upgrade.

Yes, conda has it too. As you say it would be best to use conda/uv rather than git to pin the adequate version.

This could be a drawback if you don't like to require a git commit for dependency upgrades.

On the contrary, I believe it is essential to keep dependency versions in the git log.

---

As said, I'll look into it. I am not familiar with uv (yet!) and must check which version of genanki is ok to use without causing too much changes. I may need a couple weeks to find the time.

Thank you for the work! 👍 🔆

[bbc2]

I am however quite afraid of removing the pinned submodule version of genanki. Genanki has evolved a lot since many years. It is now an even better tool, but I would honestly not want to dig into updating the present repo to fit new API requirements for genanki. I will look into what's needed.

Right, that seems like a reasonable fear. I think I have already been able to built the deck with 0.13.1 (with the code in this PR; actually, that's probably what I've always used so far), but I can't say I've examined the API changes in details.

For info, if you want to pin a commit for a particular repository, you can do:

uv remove genanki # Optional, just to remove the `>=0.13.1` constraint added earlier.
uv add git+https://github.com/remiberthoz/genanki@788fbbe0f5fbb58acc67da580887cffa1ee2dcaf

That will record this particular commit reference in pyproject.toml. and uv.lock.

And if you want to keep the git submodules instead:

git submodule update # Ensure we have the right stuff in `./genanki`
uv add ./genanki

That should be fine but it feels like it could be a bit less easy to work with.