Lock in installable Python requirements (security/stability) and evaluate using dependabot

[chennes]

Right now the ALLOWED_PYTHON_PACKAGES.txt file is explicitly not a requirements.txt-formatted file. It does not accept any version information, but instead relies on pip to install whatever version is available. This has two major problems: first, it's entirely possible to install an addon that could have been compatible with other installations, but because of the order it got installed in, pip brought in versions of dependencies that conflict with a later-to-install package. Second, from a security perspective, we allow pip to just grab the latest version of whatever package is requested, and aren't exercising any control over trusted versions -- this is widely considered a bad practice for dependency management.

An alternative is to treat ALLOWED_PYTHON_PACKAGES.txt as a fully-requirements.txt-format file, including version information, and use it as a "constraints" file when using pip to install Python dependencies. We can programmatically ensure that all FreeCAD addons share the same set of version requirements, and no package ever installs a dependency in conflict with another. We can also use Dependabot to evaluate those versions and notify us of updates as they become available. The Addon Manager can proactively note changes to this file and display update availability to users without having to scan all installed packages for possible updates.

[mnesarco]

uv is becoming the standard right now in the industry, so it means pyproject.toml is the more natural option in my opinion. pylock.toml is more like a theoretic future as PEP 751 was accepted just in March-2025. So it is used by nobody, not tooling, etc... requirements.txt is way too legacy, widely spread but nobody wants to keep it in the future.

What I think is that we can ditch pip completely and use just uv. but in case we want pip, we can generate requirements.txt from pyproject.toml at any moment with a single command: uv export --no-hashes --format requirements-txt > requirements.txt So having pyproject.toml means we also have requirements.txt for free.

[chennes]

How would we distribute uv?

[mnesarco]

How would we distribute uv?

pip install uv LOL 😂😂😂

I was talking about the ALLOWED_PYTHON_PACKAGES.txt file in the server context. So I was thinking on the server side of the AddonManager because ALLOWED_PYTHON_PACKAGES.txt is not actually used by AddonManager to feed pip on the client device, you are installing packages programatically using pip as they are declared in package.xml without version checks per addon. If I understood well, you are asking to feed Dependabot right?

So the file is used as a whitelist, it is not used to call pip/uv directly on it because the user is not intended to install all those dependencies.

Anyway, package management is a rabbit hole, I proposed uv because it is actually better than pip for development, but in the FreeCAD context, probably too early to integrate at this point. Dependabot will be happy with pyproject.toml or with requirements.txt anyway so maybe follow the easier path.

[chennes]

pip install uv LOL 😂😂😂

Hah!

I am really asking about both: using Dependabot to manage the allowed versions, but also then sending that list of allowed versions to pip as a "constraints" file, so that pip only installs the versions specified there. Actually I didn't even know pip had that feature until I started looking into how I could implement such a thing. It turns out to be very easy!

[mnesarco]

I am really asking about both: using Dependabot to manage the allowed versions, but also then sending that list of allowed versions to pip as a "constraints" file, so that pip only installs the versions specified there. Actually I didn't even know pip had that feature until I started looking into how I could implement such a thing. It turns out to be very easy!

In that case the pip's constraints is the lowest risk option and it is a very valid and supported solution.

[z0r0]

+1 I had no idea that you could use pip constraints either in this manner. This should work fine for the needs defined in the issue.

[chennes]

Taking a closer look at this it became clear that we really need a per-Python-version constraints.txt file, so I'm going to do a bit of refactoring before merging, and set up a CI workflow to auto-generate it for all the versions of Python that the Addon Manager supports.