use_pixi

[ReimarBauer]

An alternative setup based on pixi makes my life on the MBP easier.

[pya]

I am using pixi locally already. I made all dependencies conda-forge dependencies, except pytanis which is not available as conda package.

[pya]

These dependencies in pixi.toml work for me on macOS:

[dependencies]
python = ">=3.13,<4"
pyyaml = "*"
lektor = "*"
pillow = "*"
pydantic = ">=2.11.3,<3"

[pypi-dependencies]
pytanis = ">=0.8, <0.9"

Can you try on Linux?

[ReimarBauer]

adding pytanis to conda-forge requires

• httpx-auth
• gspread-formatting

first added.

And gspread-formatting shows a AttributeError: There is no sdist package on pypi for gspread-formatting.

[oem]

Personally I would not add other ways of setting up the project (since this is a pandora box, there are tons of ways on how to manage and locally develop python projects), that's why we picked the most basic way to manage the project, its dependencies and local development. Keep in mind that one has to always keep up to date with the development of the tools, I am sure that for example in a year a lot of things will have changed and should be updated, otherwise new contributors will be confused why the project uses such an outdated way of doing things.
But I am of course not gonna block this if everyone else wants to use pixi for example (I would not be able to and would not want to block it, naturally :) ). My motivation is to just keep the project minimal and reduce any growing maintenance cost over time, especially since we will not have a team that would commit and guarantee doing the maintenance part over the months/years.
Anyways, just my two cents, if you still like to add pixi I can do a quick review if you like. For what it's worth, I have tested and used the current setup under mac os and linux (and windows kind of, bust just under WSL2, which is identical to the bahviour under linux) without any problems.

[ReimarBauer]

Personally I would not add other ways of setting up the project (since this is a pandora box, there are tons of ways on how to manage and locally develop python projects), that's why we picked the most basic way to manage the project, its dependencies and local development. Keep in mind that one has to always keep up to date with the development of the tools, I am sure that for example in a year a lot of things will have changed and should be updated, otherwise new contributors will be confused why the project uses such an outdated way of doing things. But I am of course not gonna block this if everyone else wants to use pixi for example (I would not be able to and would not want to block it, naturally :) ). My motivation is to just keep the project minimal and reduce any growing maintenance cost over time, especially since we will not have a team that would commit and guarantee doing the maintenance part over the months/years. Anyways, just my two cents, if you still like to add pixi I can do a quick review if you like. For what it's worth, I have tested and used the current setup under mac os and linux (and windows kind of, bust just under WSL2, which is identical to the bahviour under linux) without any problems.

Managing virtual environments was becoming a nightmare – they were scattered everywhere and difficult to keep track of. Pixi solves this problem by abstracting away environment location and dependency management.
I've found in my other projects that using Pixi is the easiest solution, whether you’re completely new to Python or just need a consistent environment like another developer.

I'll be performing a final verification on different OSes. However, I expect it to work without issues because I’ve mirrored your package dependencies.

Testing was performed on both Linux and Windows architectures using a Guacamole setup to verify functionality. I created the pull request using a MBP.

Although the make command isn't natively available on Windows, the individual commands specified within the Makefile are being executed without errors.