These are the channel logs matching your query python
| 2025-11-27 | [08:50:58] <apteryx> any python team members online? |
| 2025-11-27 | [14:12:30] <sneek> flurando, ArneBab_ says: for the requests I intentionally kept request and body in the arguments to make them explicit (��� explicit is better than implicit as in Python), so people know where the variables come from. You need to use them anyway, and this way you know what they are named. |
| 2025-11-27 | [14:21:14] <flurando> ArneBab_: Got it, however, Hoot is still in early stage and support is incomplete compared to Python's or even C's. By the way, the writeup itself (or as you refer, tutorial) is not short-term, I kept backup locally in case vps exploded. It is the URL link short-term, because I don't want to afford the fee for a second year (domains). Thus, the domain would only remain still for 1 year. And for the link I |
| 2025-11-29 | [07:55:36] <flurando> If this is a bug instead of my fault, I might have no choice but use python instead, since on a tight schedule:( |
| 2025-11-29 | [08:23:55] <flurando> Amusingly, none of Guile examples, I mean those about c or development env, works on my machine. I decide to just use python as a workaround and check the cause of this later. |
| 2025-11-29 | [09:35:07] <flurando> Found a not so performative implementation on web, as a wrokaround in the end, glad not needing to touch python! |
| 2025-12-01 | [20:14:39] <FuncProgLinux> I think you can use pyproject-build-system now for that, seeing that it's Python and such |
| 2025-12-01 | [20:17:15] <FuncProgLinux> basicnpc: Been there with Go, with the vegeta tool. Reading the source for the program you need there's not much dependencies but I don't know python one bit :/ so idk if one of those uses rust or something similar |
| 2025-12-01 | [21:19:49] <Ox1de> Hi, I'm trying to install a python package using pyproject.toml. I'm looking for an example doing this. Can you recommend me something? |
| 2025-12-02 | [23:29:08] <gabber> how can i set a LD_LIBRARY_PATH when installing a package? i have a python package that needs to know where libngspice is |
| 2025-12-02 | [23:33:15] <Rutherther> yes and it's what's done in many python packages, ie. https://codeberg.org/guix/guix/src/fix%2Fmbr-hybrid/gnu/packages/python-xyz.scm#L4375 that I just found as first one |
| 2025-12-03 | [00:00:44] <gabber> ... assuming python automatically adds (cwd) to its PYTHONPATH |
| 2025-12-03 | [07:49:52] <bdju> Couldn't seem to upgrade earlier due to a python mess. I don't think I skipped anything but I was getting conflicts. Then I tried to skip things to get past it but it just keeps coming up with new things I gotta skip. Seems to happen a lot with the python packages. |
| 2025-12-03 | [07:51:52] <bdju> First it was magic-wormhole, then eyed3, then python-matplotlib, urlscan, etc. |
| 2025-12-03 | [08:22:39] <bdju> I guess the actual conflict it mentions is python-cffi. |
| 2025-11-26 | [07:19:33] <ArneBab_> sneek: later tell flurando: for the requests I intentionally kept request and body in the arguments to make them explicit (��� explicit is better than implicit as in Python), so people know where the variables come from. You need to use them anyway, and this way you know what they are named. |
| 2025-11-24 | [21:07:22] <ygrek> another qn, i see there is no python 3.12 or 3.13 in guix or gcc 16, is there some place where to track when they will be available / why |
| 2025-11-24 | [21:08:24] <Rutherther> there is python 3.12, named python-next. But no python-* packages for it. Not sure where to track for an update |
| 2025-11-24 | [21:08:49] <ygrek> why is it called -next and not regular python@ version? |
| 2025-11-24 | [21:12:03] <nckx> ygrek: Because it's not ���the python��� for the distribution at the moment, the Python that everything is built against by default. |
| 2025-11-24 | [21:13:32] <nckx> There's no technical reason it couldn't be named python but it's a social convention to make the CLI experience a bit more clear. Otherwise ���python��� on the CLI would always default to a newer python than the distro default. |
| 2025-11-24 | [21:14:14] <nckx> I.e. ���guix shell python python-foobar��� ��� very unintuitive version clash. |
| 2025-11-24 | [21:21:39] <ygrek> nckx, i hoped i can have mutliple versions of python and use them to build different venvs with non-guix managed deps. from your comment i understand it is necessary to have kind of "system" python so that all the other python-* packages work with it - makes sense. |
| 2025-11-24 | [21:40:41] <nckx> ygrek: I'm not sure that's what I meant. We don't *need* a single blessed system python, but there *is* one for maintenance sanity. The -next is a naming convention to prevent surprises in the common case. I don't know how venvs work, but you could create different independent Guix profiles (e.g., ���guix shell���) with a different python version inside of each. |
| 2025-11-23 | [13:21:32] <tplaten> /gnu/store/gyd1b5nm3jwrbmw8ccaibygx3gpgb1r4-gnucash-5.13-python |
| 2025-11-22 | [12:36:31] <rrobin> gargantua_kerr: the warning message? how about here https://ci.guix.gnu.org/log/yyig274vjpywz46zr2ighrcl9jy5m8dh-python-pytest-doctestplus-1.2.1 |
| 2025-11-22 | [12:38:20] <rrobin> e.g. locally guix build --check --no-substitutes --no-grafts python-pytest-doctestplus |
| 2025-11-21 | [21:28:40] <cbaines> it's possible there's an existing issue, but this could have also been introduced with the changes on python-team |
| 2025-11-21 | [21:47:04] <cbaines> Rutherther, it's possible you got that poppler missing files from bordeaux.guix.gnu.org, but only if you were using python-team before it was merged |
| 2025-11-20 | [10:07:19] <df0> ooh, looks like python-team branch has been merged |
| 2025-11-13 | [06:51:29] <rekado> apteryx: in commit c23b9a10174ce304cfc7a87aa70759364fcb76e6 did you accidentally replace define-deprecated-package with the more verbose (define-public python-libxml2 (deprecated-package ...))? |
| 2025-11-10 | [09:53:41] <cbaines> any ideas why inkscape on the python-team branch is failing to build for x86_64-linux https://data.qa.guix.gnu.org/gnu/store/fngzilrjv98glhd7ya1845z3zjk6k0ka-inkscape-1.3.2.drv |
| 2025-11-09 | [20:35:49] <Rutherther> Guest92: there are multiple reasons, but generally because something requires them to be, be it lack of enough work on the package to do it other way round or some constraints that make it really hard to do otherwise, ie. for python libraries and their dependencies, they are just propagated and it would be very hard to do it other way. That's because of how python works - just loads everything from a single PYTHONPATH, so it's not really possible to... |
| 2025-11-06 | [21:58:39] <ngz> Hello. I���m looking for the pyside6-uic tool in Guix repository, but I can���t find it. There is python-pyside-2-tools for PySide2, which includes uic, but no equivalent for PySide6. Am I missing something? |
| 2025-11-06 | [22:05:12] <ieure> ngz, python-pyside-6 |
| 2025-11-05 | [13:10:08] <ManhattanArboris> Hello! I have a question about package development workflow. I am trying to fix this bug: https://codeberg.org/guix/guix/issues/3395 . The issue is missing inputs in the package definition of python-pyqt. I have created an alternative package definition modifying python-pyqt and frescobaldi (pasted here: https://paste.debian.net/1404621/ ). When I |
| 2025-11-05 | [13:10:08] <ManhattanArboris> run with `guix shell -v3 --container --development --file=python-pyqt-pdf.scm -K', the fix to pyqt works (I can open python and run `from PyQt6 import QtPdf` successfully), but I can't get frescobaldi to open for testing the container. |
| 2025-11-04 | [14:16:22] <janneke> still fighting with mixed rust/python package python-polars-runtime-32 |
| 2025-11-04 | [19:52:14] <cdegroot> Smells like SREs like it most, and they have a history of chasing bad languages ;-) (Perl, Python, Golang, I guess they're now all aboard the Rust bandwagon? Each one of them unfit for what they need, they should've learned Guile back in the day) |
| 2025-11-04 | [23:20:06] <nixos-liveboot> also, the installer kept failing several times during the bootstrap package fetch step (TLS handshake errors when fetching guile/gcc/python/ruby etc). retried a few times and it eventually worked, but it wastes my time and your bandwidth. |
| 2025-11-02 | [03:08:10] <vhns> seems python-sphinx is failing to build? https://paste.sqt.wtf/1a70c5@raw |
| 2025-11-02 | [17:17:42] <sneek> montokapro, lfam says: I think you can set #:ruby to a package variable name in your package's arguments field. Similar to how #:python can be set, and of which there are lots of examples |
| 2025-11-01 | [09:46:41] <csantosb> Good morning Guix ! I'm upgrading a couple of Python packages, and the questions arises about propagating optional dependencies, do we ? |
| 2025-10-31 | [11:18:08] <efraim> I'm flexing my python, getting reprotest up to date. it builds packages multiple times with varying some environment variables to see how reproducible packages are |
| 2025-10-31 | [23:42:47] <Deltafire> anyone know the eta of python-branch merge? |
| 2025-10-27 | [18:58:36] <FuncProgLinux> It's a Python GUI that exposes some "dconf" settings not available on the MATE UI's. It also allows you to save panel layouts and change compositors easily. But it's been stale for years, many distributions ship it but I don't want to upstream it to guix because it's third-party MATE software. |
| 2025-10-24 | [23:13:05] <gabber`> doesn't the 'patch-shebangs patch for example python scripts with a `#!/usr/bin/env python3' shebang line? |
| 2025-10-22 | [09:21:07] <lilyp> can anyone build python on an unprivileged daemon? |
| 2025-10-21 | [12:08:28] <tux1c```> what is the policy of python packages whose dependencies are pinned to an older version of a python package? is it fine to just patch the '==' to '>=' (given that it builds with the newer minor version of the dep)? |
| 2025-10-19 | [13:12:34] <tux1c> is it safe to assume that nobody (officially) is currently working on packaging python-uv if I can't find any mention of that on either the codeberg's issues/PRs nor the python-team branch? |
| 2025-10-19 | [13:15:46] <tux1c> untrusem: oh I see, I expected it to be called 'python-uv' but I see why it isn't called that, great, thank you so much |
| 2025-10-19 | [15:51:50] <tux1c> err... or maybe it doesn't, I'm trying to update `python-pydantic-core` which in turn requires some updates to (gnu packages rust-crates) as the former includes (cargo-inputs) which is a function provided by the latter file |
| 2025-10-19 | [21:50:20] <tux1c`> hi, I'm trying to update `maturin`, it needed a small change to it's patch and I think I'm ready, but it's one of those python-rust cross programs and has it's crates defined in (gnu packages rust-crates), the top of the file mentions it's managed by `guix import` but if I run `guix import crate maturin` the definition i get back is bare (doesn't list out the packages), is there an automatic way to extract all the new dependencies of |
| 2025-10-14 | [01:10:03] <FuncProgLinux> Kolev: I moved to emacs because vim/neovim was lacking for me :s and I didn't like that the plugins were a language soup. Some vimscript, some python, some typescript... |
| 2025-10-14 | [10:27:28] <adanska> currently working on fixing mutter on gnome-team. needed to update python-dbusmock, which in turn has required tweaking in a few packages. |
| 2025-10-14 | [11:10:19] <adanska> should I put my PR for the python-dbusmock updates seperate from my mutter fix PR? One depends on the other so I dont think i should, but looking for a second opinion :) |
| 2025-10-14 | [17:24:16] <ekaitz> i'm sure that those who learned scheme first are uncomfortable writing python |
| 2025-10-14 | [17:25:50] <flypaper`> actually learned python first, but i find lisps easier to program in. |
| 2025-10-14 | [17:28:19] <ekaitz> i also learned python first and now i'm uncomfortable writing python flypaper` |
| 2025-10-10 | [10:17:43] <charlesroelli> Hi all. If I do "guix package --dry-run --install python python-toolchain", I get an error about conflicting entries for python. If I do "guix shell python python-toolchain" there is no error and "ls -l `which python`" points in the python-toolchain folder. Why does the second command not signal an error? |
| 2025-10-10 | [10:22:49] <futurile> charlesroelli: you need `python-wrapper` in your guix-shell invocation. |
| 2025-10-10 | [10:23:38] <futurile> charlesroelli: you can see the details of python-wrapper with 'guix search python-wrapper' - all it's doing is making python3 available as python |
| 2025-10-10 | [10:24:15] <futurile> charlesroelli: your first one `guix package --dry-run --install python python-toolchain` should be telling you the specific packages that are conflicting in your default profile |
| 2025-10-10 | [10:32:18] <charlesroelli> Thanks futurile. Even in a temporary profile, e.g. with "guix package --dry-run --profile=`mktemp -d` --install python python-toolchain", the command still fails because the "python" and "python-toolchain" are (I think) not meant to be used together. I'm curious why "guix shell" does not also show an error in this case. |
| 2025-10-10 | [10:36:38] <charlesroelli> We found the incompatibility between python and python-toolchain in https://codeberg.org/guix/guix/issues/3345. I guess there is some design difference between "guix package --install" and "guix shell" that explains the lack of an error in "guix shell", but I don't understand it. |
| 2025-10-10 | [10:42:05] <futurile> why are you trying to install both anyway, the info for python-toolchain says it includes python? |
| 2025-10-10 | [10:42:35] <futurile> so I think you only need python-toolchain and python-wrapper, on the assumption that you're trying to do some sort of python development |
| 2025-10-10 | [10:48:22] <futurile> charlesroelli: I don't know about `guix shell`, but the `guix package --install` is definitely because you can't use `python` and `python-toolchain` together. It explictly tries to tell you they are conflicting 'profile contains conflicting entries for python' |
| 2025-10-10 | [10:57:31] <Rutherther> charlesroelli: another thing is that python-toolchain is a 'historic' wrapper for python propagating python and inputs that were earlier necessary for building. 1. It shouldn't really be used in shells, 2. it's not necessary to use it - you can just use python, python-pip etc. |
| 2025-10-09 | [13:50:46] <pinoaffe> shameless PR-bump: could someone take a look at https://codeberg.org/guix/guix/pulls/2286 (adding python better-adbsync), https://codeberg.org/guix/guix/pulls/2353 (adding python bindings to mupdf, adding an emacs package based on those bindings), or https://codeberg.org/guix/guix/pulls/2881 (adding xmlbird and birdfont, a vala lib and a vala font editing suite)? |
| 2025-10-09 | [19:12:55] <postroutine> I dev web apps in Python/Django for many years. I have known the old virtualenv, Docker then Podman. And I wonder what would be the Guix way. |
| 2025-10-09 | [22:52:51] <untrusem> hello all, I am trying to fix this python-gbinder pacakage to that waydroid builds but it is giving me a build error https://paste.debian.net/1400237/ , here is the package defination file https://paste.debian.net/1400238/ |
| 2025-10-09 | [22:57:45] <untrusem> yep, when I extended the dbus service to add waydroid to list, the python-gbinder failed to build failing waydroid along with it |
| 2025-10-09 | [22:59:30] <char> if it fails outside of guix build, then it sounds more like a python problem than a guix problem no? |
| 2025-10-09 | [23:05:01] <untrusem> tried building with pip to in a python venv, yet it doesn't build |
| 2025-10-07 | [19:14:41] <ieure> FuncProgLinux, As for the warning, there are probably >1 package which satisfy "python@2", are you using a manifest or something? |
| 2025-10-07 | [20:51:25] <ieure> FuncProgLinux, FYI, `guix shell -m manifest.scm' doesn't give me any warnings about Python. |
| 2025-10-06 | [22:26:19] <FuncProgLinux> I thought yt-dlp was python |
| 2025-10-05 | [16:47:53] <hanker> when packaging Python, should linters (e.g. black) be included in `native-inputs` ? |
| 2025-10-04 | [09:32:29] <mroh> untrusem: this project looks more like a python-build-system, no? the error in the build.log is from the other project you pastet, havent looked at that. |
| 2025-10-04 | [09:37:09] <untrusem> its written in python, but provides a meson.build file and also mentions it the docs, also I found the newer version is dependent on https://github.com/ignis-sh/ignis-gvc , which have another subproject which https://gitlab.gnome.org/GNOME/libgnome-volume-control.git . |
| 2025-10-04 | [09:37:48] <untrusem> I tried the flake.nix which itself uses python venv to install the project in the end, its so mixed up |
| 2025-10-04 | [10:08:04] <mroh> untrusem: you already unbundled that volume-control thing, no? But it doesnt build. I am not sure, but I would try the other route and check out the original project with (recursive? t). Then, I guess you need to split the build-phase in two, one meson-build for the now checkouted subproject and one python phase. But this is just another (happy) hack to make it work. In the long run, you are right, unbundling is better. For that make the... |
| 2025-10-04 | [14:30:03] <untrusem> this happens when I try to do `guix build python-pyqtwebengine` |
| 2025-10-03 | [17:42:10] <untrusem> the just have python's requirement.txt |
| 2025-10-03 | [17:45:50] <untrusem> it just makes an python venv and install from there lol |
| 2025-10-02 | [09:17:29] <simendsjo> I managed to reconfigure my home! I ended up disabling the tests for python-xmldiff (my system still works at least), patchelfing libxml2.so.2 to libxml2.so.16 for a program, and removing three fonts. This has been troublesome times. |
| 2025-10-02 | [09:32:17] <simendsjo> futurile: Yes, this whole libxml, mesa-updates, python-updates situation has been problematic. I'm wondering why things have been merged even though they are causing so much troubles? Is it because they require full world rebuilds and there simply is not enough resources available for building everything to detect the issues? |
| 2025-10-02 | [12:25:01] <identity> zlqrvx-: ���python files��� is pretty vague, be more specific; where is the code that installs the files? in the phases? again, be more specific |
| 2025-10-02 | [12:30:56] <pinoaffe> zlqrvx-: first of all, try to mention that this change includes python files in build output, *which* python files need to be included, and *why* |
| 2025-10-02 | [12:32:04] <identity> hm, the change is just #:include #~(cons* "\\.py$" %default-include) so i guess ���python files��� is fine. some thing like ���#:include python code required at runtime��� (not sure if using ���#:include��� as a word is okay but whatever) |
| 2025-09-30 | [11:01:19] <efraim> nutcase: I'm not sure why it failed for you in 1456 but I know there's been some changes in the python- and pyproject- build systems so that might've triggered something |
| 2025-09-30 | [15:08:48] <civodul> warning: 'python-setuptools-next' is deprecated, use 'python-setuptools' instead |
| 2025-09-30 | [18:36:53] <yelninei> gabber: the fix is to also add python to inputs (or disable the python extension when cross compiling) |
| 2025-09-30 | [18:38:17] <yelninei> the first one would be the correct one but that is a world rebuild, disabling the python extension just for cross compiling would be easy |
| 2025-09-30 | [18:49:59] <FuncProgLinux> Not trying to boss anyone around. Just came to my mind that, if podman is already supported in Guix and such support is better than the docker one where compose is still the python version. Wouldn't it free some weight on the maintainers? |
| 2025-09-30 | [19:39:17] <FuncProgLinux> Rutherther: I only submitted a PR but I don't want to nag anyone into reviewing it, since I've noticed the issues & PR's regarding python have some maintainers busy |
| 2025-09-30 | [23:52:53] <ieure> simendsjo, I still can't `guix home reconfigure' because the python branch that merged last week or so broke stuff in my profile :/ |
| 2025-09-26 | [11:09:53] <cbaines> my fun for this morning is that the #f license of python-id is breaking the data service |
| 2025-09-26 | [14:02:54] <jlicht> guix shell in the guix repo seems to run into issue with building python-u-boot-pylib (which is required by patman) |