Re: 5c8369d6c1 gnu: Add python2-twodict ?
Hello Raghav, Raghav Gururajan writes: [...] >> Python 2 is EOL since a long time now > > Ah I see. I didn't know that. > >> package youtube-dl-gui is from 2018 and the release 0.4 from 2017. >> Well, I do not know if it is worth to update such package. :-) > > I first thought the same, but it seems the app is feature complete and > no additional changes. > > That said, considering deprecation of python2 by python upstream, this > package should have been ported to python3. > >> I propose to deprecate this package because it will be removed soon or later. > Yeah, since python2 is deprecated. We could deprecate > youtube-dl-gui. Should we do this is as a batch, removing all python2 > packages? Perhaps youtube-dl-gui could be removed along the python2 *leaf* packages that are orphaned as a result. The consensus for Python 2 packages is that they have to go, but that it's OK for their removal to be gradual. They tend to break because upstream often stops supporting Python 2 and can thus be phased out naturally when it happens this way. It's a good exercise to try to "free" important packages from any Python 2 appearing in their closure. Thanks, Maxim
Re: Temporarily stepping back from Guix
Hi Kei, Kei Kebreau writes: > Hello all, > > > FYI, I'll be turning in my commit access this week! I'm caught in the > middle of many different transition periods in my life and will be > taking some time away from the GNU Guix project as a result. Perhaps > in the mid-term future (a year or so?) I'll be able to return, but for > now, as a matter of security, I'm backing away. I'll still be using > Guix and admiring all the great progress we have made and will make in > the future! This project has been a great introduction to the world of > free software, and I hope to work with you all again sooner rather > than later. Thank you for your diligence! I wish you the best of luck with the new challenges life has brought up to you. Have fun, and know that we'll be happy to have you back if you ever miss the good hack! :-). Thanks, Maxim
Re: Temporarily stepping back from Guix
Good luck! Thank you and well wishes! I hope whatever is ahead for you is exciting, and that we get to see you around here more too :) Kei Kebreau writes: > Hello all, > > > FYI, I'll be turning in my commit access this week! I'm caught in the > middle of many different transition periods in my life and will be > taking some time away from the GNU Guix project as a result. Perhaps > in the mid-term future (a year or so?) I'll be able to return, but for > now, as a matter of security, I'm backing away. I'll still be using > Guix and admiring all the great progress we have made and will make in > the future! This project has been a great introduction to the world of > free software, and I hope to work with you all again sooner rather > than later. > > > Thanks as always, > > Kei
Re: Temporarily stepping back from Guix
All the best, Kei :)
Re: Questions regarding Python packaging
Hi Lars-Dominik, Am 28.06.21 um 13:59 schrieb Lars-Dominik Braun:* Not installing pip by default might break some user's environments. Anyhow, since using pip in guix is not such a good idea anyway, this should be okay. True. We could rename python→python-minimal-interpreteronly (or similar; given that python-minimal already exists) and python-toolchain→python to work around that. What should be the use of having a package without pip? Anything else than saving a few KB? [setuptools-shim has been removed] Is this relevant though? I doubt many packages are still importing distutils and the few that do can be patched. Was I wrote: This code is still in pip, so I assume it is still relevant. I don't think patching is a good idea. It requires effort (implementing, reviewing), which can be saved by keeping exisiting and tested code. set-SOURCE-DATE-EPOCH: This implementation makes the code depend on wheel and wheel being used for installation. Technically it depends on the wheel builder understanding SOURCE_DATE_EPOCH (not necessarily python-wheel). I’d say that’s acceptable and it’d be preferable to fix build systems not respecting this variable imo. For this case please change the comment not not referring to wheel in this way. More something like "we expect the builder to support SOURCE_DATE_EPOCH, like wheel does" Anyhow, *m not actually convinced that we should throw away the old code. I can imagine in the next cuple of years quite some new build-systems to arrive, most of which will most probably not support SOURCE_DATE_EPOCH in the beginning, and thus making package's life harder. Why has rename-pth-file been removed? Are you sure .pth-files are never created anymore nowerdays? Given that easy-install has been deprecated I think it’s safe to remove this phase and flag any packages creating this easy-install.pth as broken. (There are, however, legitimate packages creating files like ruamel.yaml-0.15.83-py3.8-nspkg.pth.) What exaclty do you mean with "flag as broken"? Will anybody (you? ;-) verify *all* current packages to not be "broken" prior to merging this change? Anyhow, again, I'm not convinced we should remove this phase now. .pth-file are deprecated only, but still supported. By removing this phase we might create conflict cased we can not foresee. And I would keep it even if one analyzes none of the current packages is "broken" - just do be on the save side fpr avoiding user trouble. (These issues will show up at the user, and are hard to track down, since noone will think about .pth files) python-hashbang: Isn't this done already by the normal "patch-shebangs" phase after install in gnu-build-system? (BTW: these are called *she*bangs). Afaik the function patch-shebang expects a leading slash and thus it does not replace this “special” shebang (see https://www.python.org/dev/peps/pep-0427/#installing-a-wheel-distribution-1-0-py32-none-any-whl; Spread, point 3). IC. Please add a comment to make this clear (e.g. "handle shebang of scripts generated by wheel missing leading slash") * I suggest to have phase compile-bytecode still honor older versions of python I’m not sure what you mean. compileall is also part of Python 2. The old code did not compile the source for Python <3.7. Please see the comment of the old code for rational. As I Python developer I nowerdays would expect pip and venv (which is part of the std-lib - but not the virualenv, which is a separate module) to be availalbe when installing "python". Anyhow I could live with pip being a separate package. If we keep setuptools/pip bundled, we don’t have to do any of this pypa-build dance. We could also modernize python-build-system around `pip install` and just be done with it. (I don’t have a proof-of-concept for that yet.) AFAIK this might not be true if other build systems not using setuptools at all might show up. And isn't this the main reason for all your work? The gnu-build-system already provides the "unzip" binary (used in phase "unpack"). So we could simply use this. Otherwise I recommend using the Python zip module, as this is what is used for creating the zip-archives :-) I’m using Python’s zipfile module already. Fine, so you can safely remove the respective comment ;-) -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Temporarily stepping back from Guix
On Mon, Jun 28, 2021 at 03:58:05PM +, Kei Kebreau wrote: > Hello all, > > > FYI, I'll be turning in my commit access this week! I'm caught in the middle > of many different transition periods in my life and will be taking some time > away from the GNU Guix project as a result. Perhaps in the mid-term future > (a year or so?) I'll be able to return, but for now, as a matter of > security, I'm backing away. I'll still be using Guix and admiring all the > great progress we have made and will make in the future! This project has > been a great introduction to the world of free software, and I hope to work > with you all again sooner rather than later. > > > Thanks as always, > > Kei > I'm sorry to see you go and wish you the best. I do hope you find your way back eventually! -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: 5c8369d6c1 gnu: Add python2-twodict ?
Hi Zimoun! What is this point of the commit: 5c8369d6c1 gnu: Add python2-twodict. ? The package is used by youtube-dl-gui for updating it at 0.4. I Yes, its for youtube-dl-gui. guess this package is Python 2 only, correct? TwoDict is can be used with either python 2 or 3. (Note the commit message seems wrong, IIRC.) I packaged twodict both as python-twodict and python2-twodict. Thought I only wanted the latter, I did the former to make it available in guix. Python 2 is EOL since a long time now Ah I see. I didn't know that. package youtube-dl-gui is from 2018 and the release 0.4 from 2017. Well, I do not know if it is worth to update such package. :-) I first thought the same, but it seems the app is feature complete and no additional changes. That said, considering deprecation of python2 by python upstream, this package should have been ported to python3. I propose to deprecate this package because it will be removed soon or later. Yeah, since python2 is deprecated. We could deprecate youtube-dl-gui. Should we do this is as a batch, removing all python2 packages? Regards, RG. OpenPGP_signature Description: OpenPGP digital signature
Temporarily stepping back from Guix
Hello all, FYI, I'll be turning in my commit access this week! I'm caught in the middle of many different transition periods in my life and will be taking some time away from the GNU Guix project as a result. Perhaps in the mid-term future (a year or so?) I'll be able to return, but for now, as a matter of security, I'm backing away. I'll still be using Guix and admiring all the great progress we have made and will make in the future! This project has been a great introduction to the world of free software, and I hope to work with you all again sooner rather than later. Thanks as always, Kei
5c8369d6c1 gnu: Add python2-twodict ?
Hi, What is this point of the commit: 5c8369d6c1 gnu: Add python2-twodict. ? The package is used by youtube-dl-gui for updating it at 0.4. I guess this package is Python 2 only, correct? (Note the commit message seems wrong, IIRC.) Python 2 is EOL since a long time now and the last commit of the package youtube-dl-gui is from 2018 and the release 0.4 from 2017. Well, I do not know if it is worth to update such package. :-) I propose to deprecate this package because it will be removed soon or later. WDYT? All the best, simon
guix.vim 0.2 released
guix.vim, a vim plugin for working with Guix, is now at 0.2.0. New functionality available in this version is the addition of the ':Guix' command. Any command which is available from the command line should work with :Guix inside vim. Existing functionality includes limited support for the 'guix' filetype, which supports the ':make' command in lieu of '!guix build -f %' and integrates nicely with Dispatch.vim. Currently guix.vim depends on the terminal feature of vim but work is ongoing to have it also use background jobs. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Questions regarding Python packaging
Hi Hartmut, > sorry for being late for commenting on this (the time I can spend on > guix is rather limited atm). no problem, same thing on my side. > * > > Not installing pip by default might break some user's environments. > Anyhow, since using pip in guix is not such a good idea anyway, this > should be okay. True. We could rename python→python-minimal-interpreteronly (or similar; given that python-minimal already exists) and python-toolchain→python to work around that. > * > > "use-setuptools" is gone. There are still about 10 packages with > "#:use-setuptools #f" - which means they are (expected to be) > incompatible with setuptools for some reason. You might want to > check whether these packages actually still can't be packages with > setuptools. Yeah, I’ve seen those, but the number was too small to bother for now. I’ll have a look later. > * > > setuptools-shim has been removed. I don't think this is a good idea, > since this peace of code enforces packages to be actually build with > setuptools instead of old distutils. This code is still in current > pip, so I assume it is still required. > > (This shim ensures setuptools is used, even if setup.py only imports > distutils. And setuptools is required for some options like > ""--single-version-externally-managed" - as the comment for the shim > says.) Is this relevant though? I doubt many packages are still importing distutils and the few that do can be patched. > * > > set-SOURCE-DATE-EPOCH: Please keep the verbose rational. It's much > more helpful than the new one-line comment. You mean the one from the now-removed ensure-no-mtimes-pre-1980? Sure. > * > > set-SOURCE-DATE-EPOCH: This implementation makes the code depend on > wheel and wheel being used for installation. Technically it depends on the wheel builder understanding SOURCE_DATE_EPOCH (not necessarily python-wheel). I’d say that’s acceptable and it’d be preferable to fix build systems not respecting this variable imo. > * > > Why has rename-pth-file been removed? Are you sure .pth-files are > never created anymore nowerdays? Given that easy-install has been deprecated I think it’s safe to remove this phase and flag any packages creating this easy-install.pth as broken. (There are, however, legitimate packages creating files like ruamel.yaml-0.15.83-py3.8-nspkg.pth.) > * > > python-hashbang: Isn't this done already by the normal > "patch-shebangs" phase after install in gnu-build-system? (BTW: > these are called *she*bangs). Afaik the function patch-shebang expects a leading slash and thus it does not replace this “special” shebang (see https://www.python.org/dev/peps/pep-0427/#installing-a-wheel-distribution-1-0-py32-none-any-whl; Spread, point 3). > * > > I suggest to have phase compile-bytecode still honor older versions > of python I’m not sure what you mean. compileall is also part of Python 2. > pypa bulld is where the PyPA is pushing towards. Anyhow, as of today, as > far as I can see, adoption is low. Of pypa build? That is true. > AFAIK fhere is no standard way for running tests in python. pytest seems > to be the most modern test-system. Anyhow packages still use nose or tox > (which again might run pytest or nose, with parameters fetched from > tox.ini). So I'm afraid, there is no general rule. > > Did the PyPA publish some recommendations or PEP on this? I’m not aware of any accepted PEP’s. There is a discussion about the removal of `python setup.py test`: https://github.com/pypa/setuptools/issues/931 And a proposal for pyproject.toml going nowhere: https://discuss.python.org/t/proposal-for-tests-entry-point-in-pyproject-toml/2077/2 > As I Python developer I nowerdays would expect pip and venv (which is > part of the std-lib - but not the virualenv, which is a separate module) > to be availalbe when installing "python". Anyhow I could live with pip > being a separate package. If we keep setuptools/pip bundled, we don’t have to do any of this pypa-build dance. We could also modernize python-build-system around `pip install` and just be done with it. (I don’t have a proof-of-concept for that yet.) > "python-toolchain" sounds oversized for me. Would this include the > C-compiler, too (which one? maybe I want to build cross). I'd rather not > have such a package. See suggestion above wrt renaming. > The gnu-build-system already provides the "unzip" binary (used in phase > "unpack"). So we could simply use this. Otherwise I recommend using the > Python zip module, as this is what is used for creating the zip-archives > :-) I’m using Python’s zipfile module already. Cheers, Lars
