Search guix IRC channel logs

These are the channel logs matching your query python

2023-01-31[11:36:08] <gabber`> my relatively lean system config fails to build due to python-matplotlib (which seems to be a dependency of font-abattis-cantarell). i don't use gnome or mate (which seem to depend on that font).
2023-01-31[11:43:52] <gabber`> it's /gnu/store/yrclrqxr5jpndsqakjjqyqlqyl1kbik2-python-matplotlib-3.5.2.drv which fails to build. can others reproduce that failure?
2023-01-31[11:52:01] <abrenon> (/gnu/store/gk9s8b30vdq7mm4h52jgvc052sxqvrif-python-matplotlib-3.5.2)
2023-01-31[12:01:50] <gabber`> abrenon: thanks! that seems to work! the CI has not gotten to rebuild the font but i guess something between yesterday and now broke python-matplotlib
2023-01-30[12:02:00] <tschilptschilp23> Hi! Does anyone know why chromium depot_tools would not recognize my python? I'm trying to install dart from a shell, but get this result -- .
2023-01-29[01:36:50] <herman> my pip3 reported attribute error: module contextlib has no attribute AbstractContextManager. I checked /gnu/store/ (seems that's where everything resides) and found 5 python-3.9.9 with different prefix like "12juh2khrkglgugfusgfiluf-". in 1 of them, the file holds content, and AbstractContextManager is there, the others' empty.
2023-01-29[01:37:28] <herman> does anyone know what mechnism is used to specify which python is used?
2023-01-29[19:42:22] <janneke> at the time, npm had about 4x more packages than, e.g., python, ~250.000 iirc
2023-01-27[10:18:30] <akirakyle> So I've encountered something strange. In my store I have two identical versions of python with different store paths. I've narrowed it down to them being grafted versions of python, but the weird thing is they have identical grafts applied, the only difference is that the the grafted packages are listed in a different order in the "-builder" files
2023-01-27[14:43:26] <tasty-sandwich> "[PATCH] gnu: Add package python-scapy"
2023-01-27[20:24:52] <Maya[m]1> apteryx: i want my python-level of speed /j
2023-01-25[15:11:52] <rekado> I’m a little dissatisfied with the python- prefix
2023-01-25[15:12:43] <rekado> in order to support the use as a set of modules we propagate inputs and use the python- prefix
2023-01-25[15:15:18] <apteryx> you could split the packages to have the python-something as the library, and just 'something' as the tool, but that's micro-management
2023-01-25[15:19:53] <rekado> they force us to harmonize the whole world of Python packages
2023-01-25[15:20:39] <rekado> variable names like python-*-next give me nightmares; they are bound to cause problems when someone installs a package using the variant without “-next”
2023-01-25[15:23:00] <rekado> but I wonder if there’s something in the Python load path handling that could be improved to make propagation unnecessary
2023-01-25[15:24:31] <PurpleSym> rekado: I experimented with embedding Python dependency paths into the packages themselves a while ago. That would get rid of GUIX_PYTHONPATH.
2023-01-25[16:30:28] <elb> what is the preferred way to write things like python scripts that need shebang lines without using FHS compatibility?
2023-01-25[20:28:33] <elb> OK; next Python trouble (more critical than the question about shebangs above): Python 3 aiohttp cannot verify certificates, does anyone know why that might be, and if I'm just missing a package?
2023-01-25[22:03:27] <nckx> OK Python.
2023-01-25[22:06:06] <Maya[m]1> nckx: sometimes i am sad, than i remember that i dont have to write parser for python grammar, and suddenly im good again
2023-01-25[22:36:24] <rekado> “jack_control start” aborts with a python dbus error
2023-01-25[22:47:40] <rekado> because otherwise python-dbus will try to launch a new dbus-daemon, and that fails because: “Unable to autolaunch a dbus-daemon without a $DISPLAY for X11”
2023-01-24[18:22:53] <lechner> perhaps some parallels to python packaging would help me understand the mechanics better (even though i personally never use python). in particular, i wonder if there is mechanism in the Guile build system that propagates additions to GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH and, in case there isn't, if such a facility should exist in order to avoid propagating inputs
2023-01-23[19:18:30] <apteryx> vagrantc: I don't think it does record any load-path in its .go, so you must propagate in guile just like you'd do in python, unless it's a script you can wrap
2023-01-22[03:06:27] <vagrantc> so, tests suite of python-pypdf depends on non-free .pdf files licensed under creative commons Attribution-NonCommercial-NoDerivatives 4.0 International ...
2023-01-22[17:42:25] <tschilptschilp23> I'm just trying to build GNU solfege from a guix shell with 'guix shell make gettext python gcc-toolchain texinfo swig lilypond docbook-utils pkg-config gtk+ python-wrapper python-pygobject', but at the configure stage I receive 'checking for PYGTK... no'. That's kind of expected, because I don't mention it (since I cannot find it in guix), but how does the available guix package build (or get around pygtk missing)?
2023-01-20[15:42:03] <mroh> nckx: python-build-system has (ensure-no-mtimes-pre-1980).
2023-01-20[15:42:16] <nckx> This is not a Python build system package.
2023-01-20[15:49:43] <mroh> nckx: old version of python-build-system or old version of the pkg?
2023-01-20[15:49:56] <nckx> This is not a Python build system package.
2023-01-20[15:56:02] <nckx> mroh: So (since you seem to know more of Python than I do you are now my victim) this is what it's doing: — installing a tarball of its own Python sources to /share for… Python reasons, I guess. I don't know what pip3 is or why this would be useful, and ‘If you have installed LIRC either from a package […] you don't need this’ is what tempts me to just completely dis
2023-01-20[16:05:40] <nckx> mroh: Is installing a source tarball like this something that is done/sane/common in Python land? I've never encountered it.
2023-01-20[16:09:34] <mroh> I dont know much of the python land neither. I think, its uncommon to install python files with gnu-build-system?! (Have to study the makefile...)
2023-01-20[16:37:24] <apteryx> nckx: not sure what your problem is, but if a gnu-build-system package contains some python code, it could probably be split into its own package and use pyproject-build-system to build as usual
2023-01-19[00:53:41] <vagrantc> huh. well, packaging pypdf 3.2.x as python-pypdf and adding to native-inputs seems to avoid skipping diffoscope some test suites
2023-01-19[15:42:36] <apteryx> "guix install bash python python-pip python-setuptools nss-certs groff less wget openssl"
2023-01-18[01:57:24] <lechner> gnucode / right? rekado recommended it after i played with Limnoria in Python. It was a fresh breeze
2023-01-18[13:36:18] <efraim> on another note, libxslt won't cross compile on core-updates. If I move python-minimal-wrapper from inputs to native-inputs then suddenly native builds retain a reference to it
2023-01-18[13:41:58] <efraim> libxslt-1.37 needs python-3.10, i'll switch it back to 1.35 locally while I test my llvm-for-mesa patch
2023-01-18[13:45:47] <efraim> doh, 3.10 is in core-updates. I just had to change it from python-minimal-wrapper to python-minimal
2023-01-18[19:29:38] <neox> Is GTK4 supported with python under Guix System ?
2023-01-18[19:31:13] <neox> I installed the following packages : gtk, gobject-introspection, libadwaita, python, python-pygobject
2023-01-18[23:02:39] <bdju> I found that there's some CLI thing that might work, uses python. it doesn't seem to be packaged, though.
2023-01-18[23:42:11] <vagrantc> hrm. too many pypdf builds ... there appear to by pypdf, pypdf2, pypdf3 and pypdf4 guix has python-pypdf2 1.26 and python-pypdf3 1.0 ... there is also, entirely unconfusingly pypi pypdf 3.2
2023-01-18[23:43:27] <vagrantc> those changes also appear to have broken the use of pypdf2 ... and strangely, even though i can't figure out how, python-pypdf3 in guix ... fixes the test suite failures. but does not provide any of the python modules actually used.
2023-01-18[23:47:21] <vagrantc> huh. dropping guix's python-pypdf2 fixes the test suite failure that tries to use pypdf2
2023-01-15[15:56:45] <reyman> finally we say commonly that python is a mess, but that's worse with another langages.
2023-01-15[18:07:37] <podiki[m]1> that would follow things like python
2023-01-15[18:14:50] <podiki[m]1> but something that is meant to be a standalone program shouldn't; e.g. we don't require python to be in your profile to run programs in python (they get wrapped likely)
2023-01-15[18:17:44] <podiki[m]1> anyway, I can't speak to perl and such, but for python that's what I've seen in guix: drop the python or py prefix if it is more of a standalone application and it should work as is
2023-01-15[18:23:20] <podiki[m]1> one I find is naming, though guix search will find it fine anyway; the second though is for usability: I don't think we should expect a user to include perl/python/etc. to use a little utility
2023-01-15[21:01:19] <apteryx> fun, 'guix build python-pycryptodome --target=aarch64-linux-gnu' now works
2023-01-15[21:06:39] <apteryx> vagrantc: do you know what the python inputs are use for in u-boot?
2023-01-15[23:09:32] <vagrantc> apteryx: binman is used to build a variety of u-boot related things, which uses python ... of course, easiest way is to remove the input and see what breaks :)
2023-01-14[02:26:09] <Ashy> I'm trying this `guix import pypi s4cmd > s4cmd.scm` which seems to work fine but I can't figure out how to launch a shell with python-s4cmd
2023-01-14[02:26:45] <Ashy> `guix shell -L . python-s4cmd ` is throwing errors
2023-01-14[07:13:35] <podiki[m]1> python-pytest is in (gnu packages check); try "guix show python-pytest" to see that
2023-01-14[07:24:42] <vivien> Ashy, try importing (gnu packages python-xyz) and (gnu packages time)
2023-01-14[07:25:56] <vivien> If you run "guix show python-boto3" (the first input of your new package), you should get a line: location: gnu/packages/python-xyz.scm:15607:2
2023-01-14[07:26:24] <vivien> So that tells you you need to import (gnu packages python-xyz) (transformed from "gnu/packages/python-xyz.scm")
2023-01-14[07:27:08] <vivien> Similarly, if you run "guix show python-pytz" (the second input of your package) you get a hint to import (gnu packages time)
2023-01-14[07:36:23] <Ashy> ok some progress, now it's attempting to actually build the package and failing when trying to run pytest:
2023-01-14[07:42:27] <vivien> Ashy, in gnu/packages/python.scm, look at python-jupytext for instance. See the (arguments …) part, and how it replaces the check phase by invoking pytest directly. Can you reproduce that? Make sure you replace the disable-tests with the empty list '()
2023-01-14[07:47:21] <Ashy> woo success!
2023-01-14[07:49:00] <Ashy> ah yeap i see the python-jupytext example too, thanks
2023-01-14[19:48:57] <elevenkb> hello there, I'm curious about how `python` actually knows to look up stuff in `GUIX_PYTHONPATH`.
2023-01-14[19:51:06] <elevenkb> more precisely it `python-<version>-search-paths.patch`.
2023-01-13[10:55:55] <futurile> I'm trying to create/build a package (virtualenvwrapper). It has a dependency virtualenv-clone, which I've already packaged. At the moment I'm trying to debug the build of virtualenvwrapper: so I do --keep-build and now want to go into that environment. I normally do `guix shell python <package dependencies> --container` and then mess with the build in /tmp/. But, I don't know how to tell guix to
2023-01-13[11:04:56] <futurile> rekado: the package I'm working on (virtualenvwrapper) depends on another package (virtualenv-clone). The dependency package (virtualenv-clone) is not in Guix yet, I've got an scm file for it - so I can build it and install it on my machine. That's what I mean that it's "local" - the package is not known by guix yet. So when I try `guix shell python virtualenv-clone` the output is `error:
2023-01-13[11:04:58] <futurile> python-virtualenv-clone unknown package`
2023-01-13[11:08:40] <Parnikkapore_m> ah, just reread the qn, is there a reason guix shell --container python -f yourPackageDefinition.scm wouldn't work?
2023-01-13[15:00:50] <apteryx> (which doesn't currently work because of python dependencies of u-boot, which in this mode are cross-compiled too, but I'm working toward fixing that)
2023-01-12[14:31:38] <guix-helper-bot> Wrapped python programs get native-inputs in PYTHONPATH <>
2023-01-12[20:20:59] <mirai> it's a python package
2023-01-12[20:21:37] <antipode> python packages should be straightforward to simply refresh
2023-01-12[20:23:24] <antipode> Looking at the package definition, the dependencies don't appear entangled at all (except for the single versioned python-resolvelib-0.5, don't know why another version is chosen, its uncommented).
2023-01-11[16:02:57] <apteryx> hmm, python packages cannot be cross-built
2023-01-11[16:39:31] <apteryx> with python not cross-compilable, how can we even build operating system images with --target=X ?
2023-01-11[16:39:39] <apteryx> the python-build-system, I mean
2023-01-11[17:24:11] <gabber> i get "source not archived on Software Heritage and missing from the Disarchive database" on `guix lint` for a new Python package i will shortly request to merge. is this to be expected? the (source) refers to a (pypi-uri). doesn't Guix trigger the source to be stored on SWH (anymore)?
2023-01-11[17:43:38] <apteryx> 'guix build --target=aarch64-linux-gnu python-coverage' -> build system `python' does not support cross builds
2023-01-11[17:44:26] <gabber> apteryx: huh, i just did that with my package (also python build system) and this yielded no errors
2023-01-11[17:46:27] <apteryx> does python-coverage fails the same for you?
2023-01-11[17:49:17] <gabber> this works for my package as well as for python-coverage :)
2023-01-11[17:54:51] <gabber> apteryx: it might just not be possible -- does python byte-code even differ on different architectures?
2023-01-10[14:20:37] <Korn[m]> is it like python or is it like as long as the symbols line up in sequence it works
2023-01-10[15:25:18] <elb> hmmm I also have four python 3.9.9s
2023-01-10[15:29:41] <nckx> If you ‘guix pull’ and then ‘guix upgrade’ everything in your ~/.guix-profile (called your ‘user profile’), there should be a lot shared between the two. Guix (~/.config/guix/current) doesn't need some weird Python fork or anything, for example.
2023-01-10[21:00:07] <futurile> is there any reason why a particular package is in a particular file? I'm looking at packaging a python package called virtualenvwrapper, I can find some equivalent packages in `python-check.scm` and some in `python-xyz.scm`. Does it make any difference which one I add the package to?
2023-01-08[00:20:41] <rekado> while I’d like to move java-brotli to (gnu packages java-compression) I also feel bad about ripping it from its nest of brotli-adjacent package definitions (e.g. python-brotli).
2023-01-08[00:28:00] <rekado> since we also have (gnu packages python-compression) I feel that we should just move python-brotli and java-brotli away from their parent in (gnu packages compression).
2023-01-07[11:26:27] <PurpleSym1> But I agree that one module per package would be a reasonable way to split things. I mean: haskell-xyz has 600 packages, python-xyz more than 1000 and compilation times for each of them are hitting multiple seconds on a fast machine.
2023-01-07[15:51:19] <tex_milan> anyone using python-selenium? having trouble with it... `browser = webdriver.Firefox(executable_path="icecat", capabilities={'browserName': 'icecat', 'marionette': True, 'acceptInsecureCerts': True})` fails with selenium.common.exceptions.WebDriverException: Message: Service icecat unexpectedly exited. Status code was: 0
2023-01-06[22:56:31] <vivien> I fear the day we will have to split large modules such as python-xyz
2023-01-05[05:09:26] <ConvolutedSquare> lechner: what does the match part do? Is it required or can I keep it lean like the python example?
2023-01-04[12:11:52] <ennoausberlin> telmo[m]: python-psutil might be another *optional?* dependency
2023-01-04[12:20:33] <jlicht> Guix horror stories: "build of /gnu/store/....-python-... failed: No such file or directory: cargo"
2023-01-04[23:09:27] <lebowski> hi guix! i am trying to package a newer version of a python library which already in guix. the thing is - the newer version removed, so now guix gives me this error "misc-error #f "no found" () #f ". what i can do to resolve this issue?