| elibrokeit | Clark[m]: setuptools *absolutely refused* to change their own command scripts, on the rationale that "people should use pip install, and we are not touching or fixing legacy code someone might depend on" | 08:38 |
|---|---|---|
| elibrokeit | of course then they also used the bad command scripts as one of the reasons you should use pip, then removed the code from setuptools, but well... :) | 08:39 |
| elibrokeit | https://github.com/pypa/setuptools/commit/5e907629baa69e0387b241e8ef7767edf4d0ede8 | 08:41 |
| elibrokeit | setup.py install, imported ScriptWriter from easy_install | 08:41 |
| elibrokeit | now they moved this to setuptools._scripts, it is "just" a refactor and moved imports | 08:42 |
| elibrokeit | so you can patch that instead | 08:42 |
| elibrokeit | be aware they finally plan to totally remove install support ~November | 08:42 |
| elibrokeit | see also https://bugs.launchpad.net/pbr/+bug/2107732 | 08:44 |
| frickler | looking at https://zuul.opendev.org/t/openstack/builds?project=openstack%2Fpbr&pipeline=periodic&skip=0 there have been issues with the pbr CI for months already, so we got multiple things to deal with at the same time now | 12:59 |
| frickler | this is complicated by test-requirements depending on pbr for their installation, but the latter doesn't use the pbr version under test, so that's broken then, too | 13:00 |
| frickler | maybe if we would build a wheel for testresources and push it to our caches, we could work around issues like in https://zuul.opendev.org/t/openstack/build/ccf30896370f409fbdcc829ab782f244 and then go ahead to tackle the real issues | 13:17 |
| Clark[m] | frickler: you may be able to pre install pbr from the local repo before requirements or test-requirements then I think it will use that version | 13:53 |
| Clark[m] | Does that issue imply the problem is only when doing editable installs? I guess because pip will create the file when not editable? I half wonder if we can workaround this by dropping editable installs | 13:56 |
| Clark[m] | I suppose the easiest thing may be to drop the custom command scripts entirely. Accept that an entry point implementation is likely slower but functional then sort out how to stop relying on this by November? | 14:03 |
| Clark[m] | Not sure if that is helpful at all | 14:03 |
| elibrokeit | Clark[m]: no, it shows up in Gentoo package builds too | 14:53 |
| elibrokeit | it seems to be importing the implementation unconditionally at startup | 14:53 |
| elibrokeit | so that it *can* override the attributes in the event of using editable installs | 14:54 |
| elibrokeit | but also, it's overriding `setup.py install` as well | 14:54 |
| elibrokeit | more specifically it is overriding the install_* functions which are internally used by setuptools even in "modern" wheel building modes | 14:55 |
| Clark[m] | I see. Ya I wonder if we can just drop it entirely. That will probably break the wsgi scripts? But everything else would work using setuptools implementation (which may produce slow scripts?) | 15:23 |
| frickler | pre-installing pbr into the venv only helps when also adding --no-build-isolation to pip install. but with that my attempt at https://review.opendev.org/c/openstack/pbr/+/948752 seems to work for me locally. there are still testing failures though due to the develop deprecation | 15:26 |
| elibrokeit | Clark[m]: it is literally a moved import | 15:40 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!