| *** rlandy|rover|bbl is now known as rlandy|rover | 01:46 | |
| *** akekane__ is now known as abhishekk | 05:54 | |
| *** ysandeep|out is now known as ysandeep | 06:16 | |
| *** jpena|off is now known as jpena | 07:39 | |
| *** ykarel is now known as ykarel|lunch | 08:13 | |
| *** ysandeep is now known as ysandeep|lunch | 08:16 | |
| *** ysandeep|lunch is now known as ysandeep | 09:12 | |
| *** ykarel|lunch is now known as ykarel | 09:56 | |
| *** jcapitao is now known as jcapitao_lunch | 10:50 | |
| *** ysandeep is now known as ysandeep|afk | 11:15 | |
| *** jpena is now known as jpena|lunch | 11:38 | |
| *** rlandy is now known as rlandy|rover | 11:39 | |
| *** ysandeep|afk is now known as ysandeep | 12:13 | |
| *** jcapitao_lunch is now known as jcapitao | 12:21 | |
| *** jpena|lunch is now known as jpena | 12:40 | |
| *** frenzy_friday is now known as anbanerj|ruck | 12:46 | |
| jpodivin | Can I ask some questions about openstack/requirements? | 13:06 |
|---|---|---|
| fungi | jpodivin: you can, but the #openstack-requirements channel is probably a better place to do that | 13:14 |
| jpodivin | fungi: I tried that as well, although I didn't get response yet. | 13:16 |
| jpodivin | It's not really in-depth question though. It's about the practical side of things. Basically I'm interested in what to put in the `-c` argument when installing tox env | 13:18 |
| fungi | jpodivin: you mean tox -c? that's for specifying an alternate tox configuration file name or path to a different directory containing a tox.ini file | 13:19 |
| fungi | the tox documentation should cover it | 13:19 |
| jpodivin | oh, not that, I meant the pip install -c | 13:19 |
| fungi | ahh, yes pip install -c is how you specify a constraints file | 13:20 |
| jpodivin | yes | 13:20 |
| fungi | a constraints file is essentially a means of constraining the versions of requirements which are being installed | 13:20 |
| jpodivin | So the question is, which should we use. | 13:20 |
| fungi | which what? | 13:20 |
| fungi | and who is "we"? | 13:21 |
| fungi | i'm missing a bunch of context | 13:21 |
| fungi | if "we" is an official openstack project, normal tox jobs should use the upper-constraints.txt file from whatever branch of the openstack/requirements repository matches the branch of the change being tested for the project | 13:22 |
| jpodivin | fungi: well that is our case. | 13:23 |
| jpodivin | fungi: But the recent job results were ... odd. For some reason the constraint pluggy===1.0.0 prohibits us from using the pluggy<1.0 and >=0.7.1 | 13:26 |
| jpodivin | https://zuul.opendev.org/t/openstack/build/f3d3c648f67c42ab82b9410b0e8e1d12 | 13:26 |
| jpodivin | which kind of blocks our check pipeline, weirder still, we started to hit this in two projects at the same time. | 13:27 |
| *** diablo_rojo_phone is now known as Guest6075 | 13:28 | |
| fungi | jpodivin: probably the constraints update in openstack/requirements isn't tested with you project, or else it wouldn't have been able to merge an update to pluggy===1.0.0 | 13:28 |
| fungi | best to talk with the constraints maintainers about it | 13:29 |
| jpodivin | fungi: in #openstack-requirements right? | 13:29 |
| fungi | yeah | 13:29 |
| jpodivin | so, and I hate to say this, how does this constraint actually work? I thought the upper constraint just meant that everything < 'constraint' should pass. But it doesn't. | 13:30 |
| fungi | requirements changes are usually tested against openstack services and libraries with devstack, so shouldn't change outside what that set of projects can support | 13:30 |
| fungi | `pip install pluggy>=0.7.1,<1.0` asks pip to install pluggy 0.7.1 or newer as long as it's not as new as 1.x | 13:32 |
| fungi | a constraint of pluggy===1.0.0 tells pip that *if* it's installing pluggy, the version of pluggy it installs must be 1.0.0 | 13:32 |
| jpodivin | ah, | 13:32 |
| jpodivin | that's ... different than I thought. We'll have to figure this one out. | 13:33 |
| fungi | so the upper-constraints.txt file is what you might term a "lockfile" in other language packaging ecosystems, but for the whole of openstack, to indicate what specific dependency versions a coordinated openstack release was tested with, ensuring everything in openstack is coinstallable with a common set of dependency versions and that we can reproduce testing of that release years later | 13:35 |
| fungi | in stable branches | 13:35 |
| jpodivin | fungi: ok, that makes sense. | 13:39 |
| jpodivin | Thanks | 13:39 |
| fungi | you're welcome | 13:42 |
| *** fressi_ is now known as fressi | 14:14 | |
| clarkb | note that pip has added a richer lockfile system since constraints was added but it requires significantly more changes to how the packaging is done to use and as a result hasn't been done for openstack | 14:56 |
| fungi | well, the actual "lockfile" pep is still under discussion | 14:59 |
| clarkb | is it? a number of tools make use of it today | 14:59 |
| fungi | and is about things that aren't really what you would consider lockfiles | 14:59 |
| clarkb | the one I'm thinking of locks versions and checks package hashes | 14:59 |
| fungi | it's more about standardizing what poetry and, i think, flit use and calling them "lockfiles" when they really aren't | 15:00 |
| fungi | there's a never-ending thread on the python discourse about it | 15:00 |
| clarkb | https://github.com/pypa/pipfile is the thing and it definitely supports a proper lockfile | 15:00 |
| clarkb | https://github.com/pypa/pipfile#pipfilelock | 15:00 |
| clarkb | a much richer lockfile than constraints. The hash verification in particular is nice | 15:01 |
| fungi | ahh, that | 15:01 |
| fungi | yeah sorry it's poetry and pipfile the pep is trying to standardize | 15:02 |
| fungi | pipfile != pip | 15:02 |
| clarkb | sort of aiui it was fully intended to go into pip but then they drug their feet which is why all the other tools popped up | 15:02 |
| fungi | i think it's the pipfile maintainers who are the primary ones pushing the lockfile pep | 15:03 |
| fungi | and the pip maintainers seem on the fence about whether it makes sense to support | 15:03 |
| fungi | and poetry has added support for pipfile, or has a similar use case | 15:04 |
| clarkb | ya I think it uses the same lockfile syntax at least | 15:07 |
| fungi | what they're calling a "lockfile" is really more a replacement for requirements.txt though, not so much constraints | 15:16 |
| fungi | but also since poetry doesn't have a constraints feature, the folks writing the pep keep misusing the term constraints to mean something else | 15:17 |
| fungi | which is adding to the confusion | 15:17 |
| fungi | if they revised the pep to say it was about a replacement requirements list syntax, i think there would be far less contention | 15:18 |
| clarkb | fungi: the lockfile is definitely a replacement for constraints | 15:23 |
| clarkb | the pipfile replaces requirements. the pipfile.lock replaces constraints | 15:23 |
| clarkb | They continue to be separate things just as with pip today, but both attempt to be richer in the functionality they support | 15:24 |
| fungi | and you can specify things in pipfile.lock that you don't necessarily want to install? neat | 15:24 |
| clarkb | I think so, you'd just have to generate it with a larger input pipfile than what is used later to install things | 15:25 |
| fungi | the draft pep i was referring to currently under discussion is https://www.python.org/dev/peps/pep-0665/ | 15:26 |
| *** jpena is now known as jpena|off | 16:47 | |
| *** ysandeep is now known as ysandeep|out | 16:47 | |
| *** sshnaidm is now known as sshnaidm|off | 17:01 | |
| *** Guest6075 is now known as diablo_rojo | 18:10 | |
| *** diablo_rojo is now known as Guest6089 | 18:11 | |
| *** Guest6089 is now known as diablo_rojo_phone | 18:12 | |
| opendevreview | Clark Boylan proposed openstack/project-config master: Set empty nodepool resource lists on inap https://review.opendev.org/c/openstack/project-config/+/807204 | 19:01 |
| opendevreview | Clark Boylan proposed openstack/project-config master: Remove the inap provider from nodepool https://review.opendev.org/c/openstack/project-config/+/807205 | 19:01 |
| opendevreview | Luciano Lo Giudice proposed openstack/project-config master: Add the cinder-lvm charm to Openstack charms https://review.opendev.org/c/openstack/project-config/+/807206 | 19:01 |
| ade_lee | fungi, we can remove the node hold on that job , thanks! you and clarkb identified the problem correctly. I'm going to be trying to use ecdsa keys instead | 21:11 |
| fungi | ade_lee: good to have the theory confirmed, thanks! i'll free the node | 21:11 |
| *** bnemec is now known as bnemec-pto | 21:45 | |
| opendevreview | melanie witt proposed openstack/project-config master: Set launchpad bug Fix Released after adding comment https://review.opendev.org/c/openstack/project-config/+/801376 | 22:45 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!