Similar to my `uvx add-classifiers` and `uvx add-link` mini projects, recently made a `uvx set-license` to simplify that step of setting up new projects.
https://pypi.org/project/set-license/
https://codeberg.org/kfdm/set-license
Light wrapper around https://api.github.com/licenses to add the `license` line to `pyproject.toml` and write to `LICENSE.md`
#python #uvx #pipx
Well, the upgrade to #Fedora43 was almost uneventful. There was a minor issue with #wine, but everything went well after I uninstalled and reinstalled it.
Some font options were reset to the default, so everything looked "too big" after rebooting. I also had to reinstall all my #pipx packages. But that's it.
I could have waited a couple of weeks to upgrade, but I thought, "Meh, whatever, it's not #Windows." and went ahead 
Not that anyone has asked, or cares, about my podunk, backwater processes. There's a few reasons why I haven't migrated my #Python work to use #uv
1. I don't care about performance. My work is done on a potato machine and it won't make much difference, to me. For now.
2. I prefer to keep the VC funded company Astral at arms length, pay attention, and see how the tool development plays out.
3. I actually like watching individual projects like #pyenv #pipx and the rest. How they work as a community, handle bugs and new features.
I did the same with the flake8 module projects before I commited to using ruff several years ago. YMMV
Huh. This is a new one.
Somehow, I've managed to pollute my #Python pip userspace with a bunch of packages from a #Poetry project I normally work on.
Fortunately, I could just easily rebuild with #pyenv and #pipx. Just kinda weird that it happened in the first place. I might have to go back to explicitly using `poetry shell` for isolation. *shrug*
Just a little note for anyone interested...
Running ```pip-audit``` revealed a #vulnerability in pip25.2 with no #PyPI database update available yet.
The immediate fix is a manual patch update to pip 25.3.dev0 - #Development version.
Took another swing at upgrading from #debian #bookworm to #trixie.
apt-upgrade --without-new-pkgs done first, then normal apt upgrade, then apt dist-upgrade.
Checked #udd for bugs etc, plus a quick re-read of the release notes.
This time things worked better, because I fixed some sources before the upgrade and removed a couple of things I'd gotten from deb-multimedia which had compromised certain aspects of the upgrade last time I tried.
Mostly painless, and all working. I've stuck with #xfce for the desktop, at least for now whilst testing #kde in a VM.
I had to do a 'pipx reinstall-all' to fix the underlying #python in those virtual environments.
And had to do #python virtual environment upgrades in my normal venv folders for the handful of things I run that don't seem to like #pipx
All done and will now monitor and record any issues, and raise bugs if I get anything serious. But I doubt anything will be a problem given the imminent release of #trixie in the next 6 to 8 weeks.
Spent the evening upgrading from #debian #bookworm as the current stable to #trixie (which is still testing but is now well into freeze, so little will change for everyday use).
Checked the draft release notes and did the inline upgrade. Mostly okay.
Annoyances were from having to set up virtual environments again for #python apps. I tend to use #pipx and couldn't just do an upgrade, I had to refresh the #python runtime within each #pipx venv. Bit annoying, but not too onerous.
Main issue stems from a couple of apps that are not in the #debian repos.
#dvbcut hasn't been updated to be #trixie compliant, and that isn't available as #appimage or #flatpak, so that will be something I'll lose until I can sort out a docker or VM to run it if I truly need it still.
Other was trying to get #avidemux to compile and run - several fruitless hours later, and that isn't working either. For now I've gone with the flatpak but it's not official and I don't really like flatpaks if I can avoid them.
Instalarea și utilizarea pipx în Linux
Pip este un instrument popular pentru instalarea pachetelor și modulelor Pyton din Python Package Index. Cu toate acestea, în versiunile recente ale distribuțiilor, utilizatorii Pip se confruntă cu un defect de mediu gestionat extern. Aceasta este o „caracteristică” adăugată pentru a evita conflictele dintre pachetele Python instalate prin Pip și managerul de pachete nativ. Python dorește să folosiți medii virtuale separate în loc să instalați pachetul la nivel global […]https://comunitatealinux.ro/instalarea-si-utilizarea-pipx-in-linux/
#OpenSUSE in AWS still has python3.6 as system python. Every time I use a python tool and ran into python3.6 and python3.9+ compatibility issues, my heart sinks a little. I know, there are solutions like #uv, #venv, #pipx, #docker, #nix etc!
With #rust you sweat (and cry) during development but with #python (and #js), you sweat (and cry) after deployment!
I'll die on the former hill rather than the later. Thank you!
KungFuDiscoMonkey
Carl von Lesquereux
Kevin Bowen 
Unicorn-1
Mason Pines
XLBilly
Comunitatea Linux România
dilawar