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 -- http://paste.debian.net/1268955 . |
| 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 contextlib.py 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" https://issues.guix.gnu.org/60732 |
| 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: https://sourceforge.net/p/lirc/git/ci/master/tree/python-pkg/README.rst — 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> https://docs.platformio.org/en/latest/core/index.html 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 ... https://pypi.org/search/?q=pypdf 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: https://github.com/AshyIsMe/guix-python-test |
| 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! https://github.com/AshyIsMe/guix-python-test |
| 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 <https://issues.guix.gnu.org/25235> |
| 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 setup.py, so now guix gives me this error "misc-error #f "no setup.py found" () #f ". what i can do to resolve this issue? |