KiBot installed through pipx

[jaskij]

Important up front: KiBot seems to work installed through pipx with

pipx install kicost --system-site-packages --pip-args="--no-compile"

I have only just gotten a positive result from kibot-check, so it may turn out to have issues somewhere down the road, but it seems like a good point to make this issue as information - and perhaps with a request to update the docs after some more testing.

kibot-check log

As to why: we all know that pip has the potential to break system packages, so using it for global installs is a big issue.

Bit thanks to @pm5k for saving me a few hours of digging through manuals.

[set-soft]

Hi @jaskij !
I guess you have a typo, kicost instead of kibot right?

Thanks for the information, I'll add a comment in the docs.

If I understand correctly pipx tries to install applications in their own venv. Right?

From your log it looks like you are using Arch Linux or similar, did you try https://aur.archlinux.org/packages/kibot ?

[jaskij]

Yeah, it was meant to be kibot, I've been experimenting a fair amount and grabbed the wrong thing from my history.

pipx does three things:

• create a virtual environment
• install the package in there
• drop a wrapper script inside ~/.local/bin

The two flags are necessary, and do what they say on the tin.

I did see the AUR package, but didn't like the way it's done, with the hard dependency on Blender, and decided to not use it.

[set-soft]

Yeah, it was meant to be kibot, I've been experimenting a fair amount and grabbed the wrong thing from my history.

pipx does three things:

• create a virtual environment
• install the package in there
• drop a wrapper script inside ~/.local/bin

The two flags are necessary, and do what they say on the tin.

Just curious: why do you need a venv to run KiBot? I put some effort in trying to avoid this need.

I did see the AUR package, but didn't like the way it's done, with the hard dependency on Blender, and decided to not use it.

You are right Blender should be optional, you might want to contact the author of the packaging file. I guess other Arch Linux users will agree and be glad.

[jaskij]

Just curious: why do you need a venv to run KiBot? I put some effort in trying to avoid this need.

I've had bad experiences with global installs, even inside $HOME, breaking things, and judging by the fact there is PEP-668 for this now, I wasn't the only one. As a rule, I do not do pip installs outside virtual environments. You can probably find any number of more in-depth explanations of the rationale if you look up the discussions around that PEP.

[set-soft]

Just curious: why do you need a venv to run KiBot? I put some effort in trying to avoid this need.

I've had bad experiences with global installs, even inside $HOME, breaking things,

With KiBot?

and judging by the fact there is PEP-668 for this now, I wasn't the only one.

Python "packages" are broken. And the main developers favor Windows installations, making things even worst.
Most people releasing Python modules doesn't care about compatibility. So the current status is a disaster.
But this doesn't mean things can be done right.
Most Linux distros solves the issues correctly.

As a rule, I do not do pip installs outside virtual environments. You can probably find any number of more in-depth explanations of the rationale if you look up the discussions around that PEP.

I use venvs for things that are chaotic, like AI packages, which are all released in such a hurry that you will face incompatibilities as soon as you start using various together.

But I believe Python programs can integrate with Linux distros, even when they aren't part of the core distro.
This is why I try to keep KiBot working as smooth as possible with different Python and Python modules versions.

For this I need users feedback, this is why I'm asking.

[jaskij]

With KiBot?

No, not with KiBot, I haven't used it much yet.

For this I need users feedback, this is why I'm asking.

This particular user is extremely risk averse. I'd rather find a way to have KiBot working within a venv than inevitably have to fix something that gets broken down the line.

---

As a quick example, I've had... whatever, not even important, installed in my home directory, on Python's search path. Thing is, I'm using Arch, a rolling distro, and I never remember to run pip's equivalent to a pacman -Syu update. So, one day, after a system update and reboot, I found my preferred terminal application - Terminator - broken.

Turns out, whatever unimportant package I installed in my home with pip shared a dependency with Terminator. And because I didn't update that, an update resulted in a version mismatch.

The story could be any two packages, anything that has any sort of dependencies. And while Terminator wasn't critical (I've had a different terminal emulator installed), and I fixed things with some annoyance, it was still an eye-opening situation.

Bottom line is, you should never mix two update streams. They will go out of sync, the only question is when. And when they do, things break.

---

And honestly, with KiCad pushing towards the IPC API, I'm not sure if this discussion is really relevant, as you should be moving away from the SWIG pcbnew module anyway. With IPC, there is really no reason for KiBot to need access to system site packages.

[set-soft]

And honestly, with KiCad pushing towards the IPC API, I'm not sure if this discussion is really relevant, as you should be moving away from the SWIG pcbnew module anyway. With IPC, there is really no reason for KiBot to need access to system site packages.

I'll move to IPC API when it is available in some version that doesn't break twice a week.
And it won't change much about dependencies. KiBot does a lot of things that KiCad can't do, and coordinates various plugins, with their own dependencies.

[jaskij]

And it won't change much about dependencies.

It does change the crucial fact of not depending on pcbnew, the old SWIG bindings, which would mean not needing access to system site packages, meaning KiBot should work inside a virtual env with no issues. Of course I could be missing something.

[set-soft]

Ok, now I understand what you say, yes, when all is migrated, we won't need pcbnew from the system wide installed KiCad.