| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2020-04-17 | |||
| 12:00:33 | AJaeger | mordred: can you help, please? ^ | |
| 12:01:07 | dtantsur | AJaeger: there is a question re 3.5 on the first of them | |
| 12:01:20 | dtantsur | I remember discussing it on another patch, but I don't remember the resolution | |
| 12:04:26 | openstackgerrit | Andreas Jaeger proposed openstack/os-client-config master: Cleanup py27 support https://review.opendev.org/717609 | |
| 12:05:05 | AJaeger | dtantsur: I followed your suggestion - as long as shade is testing 3.5, we need 3.5 in there... | |
| 12:06:12 | dtantsur | thanks! | |
| 12:15:59 | openstackgerrit | Dmitry Tantsur proposed openstack/python-openstackclient master: Move Babel to test-requirements https://review.opendev.org/720701 | |
| 12:16:01 | dtantsur | not sure if even test-requirements is needed ^^^ | |
| 12:24:04 | openstackgerrit | Merged openstack/service-types-authority master: Cleanup py27 support https://review.opendev.org/719183 | |
| 13:38:29 | openstackgerrit | Dmitry Tantsur proposed openstack/python-openstackclient master: Remove Babel from requirements https://review.opendev.org/720701 | |
| 13:38:30 | dtantsur | updated with the recent findings ^^^ | |
| 14:49:50 | AJaeger | who's reviewing shade? Here's a change to update the jobs which we need to move forward with py27 drop, please review https://review.opendev.org/#/c/718068/ | |
| 14:54:59 | openstackgerrit | Monty Taylor proposed openstack/shade master: Update master for stable/ussuri https://review.opendev.org/719021 | |
| 14:55:18 | openstackgerrit | Monty Taylor proposed openstack/shade master: Add Python3 victoria unit tests https://review.opendev.org/719022 | |
| 14:55:34 | mordred | AJaeger: done! | |
| 14:58:56 | AJaeger | thanks, mordred | |
| 15:00:35 | openstackgerrit | Andreas Jaeger proposed openstack/keystoneauth master: Cleanup py27 support https://review.opendev.org/720742 | |
| 15:07:16 | openstackgerrit | Sean McGinnis proposed openstack/shade master: Declare py38 support https://review.opendev.org/720746 | |
| 15:31:40 | openstackgerrit | Dmitry Tantsur proposed openstack/python-openstackclient master: Remove Babel from requirements https://review.opendev.org/720701 | |
| 15:32:58 | openstackgerrit | Dmitry Tantsur proposed openstack/python-openstackclient master: Remove Babel from requirements https://review.opendev.org/720701 | |
| 15:33:38 | dtantsur | lower-constraints is quite a fragile thing | |
| 15:40:47 | AJaeger | dtantsur: it's not working as designed IMHO | |
| 15:41:15 | dtantsur | to me we should only list direct dependencies in lower-constraints.txt | |
| 15:41:20 | dtantsur | but I seem to be alone in that | |
| 15:41:52 | AJaeger | dtantsur: Let me write up something... | |
| 15:44:37 | AJaeger | dtantsur: will take a bit, I need an example | |
| 15:47:08 | dtantsur | depending on what you need, I may be able to help | |
| 15:51:53 | smcginnis | Should be able to AND the packages between lower-constraints.txt and (requirements.txt and test-requirements.txt). | |
| 15:52:26 | smcginnis | I think Doug's original reasoning for having other packages was to be able to test all other dependencies too. | |
| 15:53:10 | dtantsur | for me it's very problematic every time the list is updated | |
| 15:53:21 | dtantsur | if we include indirect dependencies (like babel now) | |
| 15:53:34 | dtantsur | I can go back to putting babel in lower-constraints | |
| 15:53:46 | dtantsur | whatever is better | |
| 15:53:57 | smcginnis | Yeah, personally I would prefer to only enforce our direct dependencies too. | |
| 15:54:19 | smcginnis | And trust that they are not installing their own dependencies unconstrained (which actually probably is a risky assumption). | |
| 15:56:20 | AJaeger | The problem is: We install package X in version 0.1, then package Y needs X in version 0.2 - and pip -U installs that ;( I need to dig out an example, this is happening often. | |
| 15:58:31 | dtantsur | is it a problem though? | |
| 15:58:46 | dtantsur | I thought the goal was to verify our minimum caps | |
| 15:59:02 | dtantsur | so that e.g. we don't put requests>=1.0 but use features from 1.2 | |
| 15:59:16 | dtantsur | indirect dependencies are not used directly, so it makes no sense for them? | |
| 15:59:21 | openstackgerrit | Merged openstack/shade master: Break out py27 job templates https://review.opendev.org/718068 | |
| 15:59:22 | openstackgerrit | Merged openstack/shade master: Update master for stable/ussuri https://review.opendev.org/719021 | |
| 16:01:03 | AJaeger | dtantsur: yes, if you change one line, everything blows up as you noticed | |
| 16:01:42 | smcginnis | AJaeger: That may be the reason for inclusing our indirect dependencies in there - to make sure that scenario doesn't happen my locking down everything and make sure we always get the versions we expect to get. | |
| 16:01:49 | smcginnis | *including | |
| 16:02:10 | AJaeger | smcginnis: but we don't - I need an example, give me somem time, please | |
| 16:02:19 | AJaeger | And then let's discuss whether I'm right or not... | |
| 16:02:48 | dtantsur | smcginnis: the other way around. if you include all dependencies, any change will likely cascade. | |
| 16:03:09 | smcginnis | dtantsur: Yes, but that would be by design, right? | |
| 16:03:09 | dtantsur | if you only include direct dependencies, you'll get into trouble only if your minimum cap conflicts with some other. | |
| 16:03:19 | dtantsur | not sure | |
| 16:03:31 | dtantsur | I see the goal of lower-constraints differently | |
| 16:03:48 | smcginnis | If we want a definitive set of requirement minimums that can be used, we need to be explicit about everything that gets installed to be able to verify it actually works. | |
| 16:04:11 | dtantsur | I only care about direct dependencies because that's what we (in a project) control | |
| 16:05:16 | dtantsur | like, in this case I have to care that something else is using babel and pytz. I don't think I should. | |
| 16:05:20 | smcginnis | But like Andreas pointed out, if we say we want version 1.0, but then an indirect dependency raises that to 2.0, we aren't actually capturing (or at least validating) what our minimum version of that lib should be. | |
| 16:06:09 | dtantsur | smcginnis: in this case the job will fail and we'll know :) | |
| 16:06:26 | dtantsur | that's literally what happened with my patch | |
| 16:06:39 | smcginnis | I'm probably missing some context. Which patch is this? | |
| 16:06:57 | dtantsur | smcginnis: tl;dr I've uncapped babel and it got pulled again down the road with a conflicting pytz requirement | |
| 16:07:49 | smcginnis | Yeah, so that points to the reason for why lower-constraints should have packages that are not in requirements and test-requirements. | |
| 16:08:00 | smcginnis | It needs to control the full environment. | |
| 16:08:11 | dtantsur | for me it points to the opposite thing :) | |
| 16:08:23 | dtantsur | I don't need this control. As a developer I don't care about it. | |
| 16:08:31 | dtantsur | Maybe we see the goals of lower-constraints differently? | |
| 16:08:42 | dtantsur | For me it's only to verify that we don't violate our minimum caps | |
| 16:09:00 | smcginnis | But going the route you are advocating, you've just pointed out that causes problems. :) | |
| 16:09:22 | dtantsur | it caused a problem because we also capped pytz | |
| 16:09:43 | dtantsur | which wasn't a direct dependency either | |
| 16:10:01 | dtantsur | or maybe it's too late for me to think clearly :) | |
| 16:11:29 | smcginnis | The reason we have it in l-c is because it is an indirect dependency that of not constrained will install a different and potentially conflicting version like you are saying. | |
| 16:11:53 | AJaeger | smcginnis: is lower-constraitns documented somewhere? | |
| 16:12:07 | smcginnis | So even if we use neither babel nor pytz directly, having them in l-c will force the exact versions to be installed and avoid conflicts like that. | |
| 16:12:35 | dtantsur | smcginnis: okay, I remembered why we stopped doing it in ironic, I think. It's fine while it works, but every time you need to update something, it's a cascading nightmare. | |
| 16:12:48 | smcginnis | AJaeger: I'm not really sure. I remember when Doug was working on it, and he had to explain some of the reasoning for the approach to me a few times, but I don't recall reading a spec or anything like that. | |
| 16:13:00 | dtantsur | anyway, if people feel I should keep Babel in lower-constraints, I can do it | |
| 16:13:05 | dtantsur | just let me know | |
| 16:13:24 | smcginnis | dtantsur: Well, again, you can argue that's by design. If you change one thing, then you have to expect there may be other packages that will also need to be raised. | |
| 16:13:42 | dtantsur | it's not unreasonable, I just've never looked at it this way | |
| 16:14:03 | smcginnis | The exercise being to find what the new lowest set of requirements are that should be expected to work. | |
| 16:14:08 | AJaeger | I found https://docs.openstack.org/project-team-guide/dependency-management.html | |
| 16:15:28 | dtantsur | updated ^^ | |
| 16:15:28 | openstackgerrit | Dmitry Tantsur proposed openstack/python-openstackclient master: Remove Babel from requirements https://review.opendev.org/720701 | |
| 16:35:07 | AJaeger | smcginnis, dtantsur|afk https://etherpad.opendev.org/p/S_6OvGeqCniK5CLVxIan is what I found out so far. | |
| 16:35:22 | AJaeger | So, lower-constraints might be working correctly - but we're usingn it in a broken way ;( | |
| 16:35:58 | AJaeger | With removing install_command suddenly you open pandora's box since none of the requirements is correct anymore ;( | |
| 16:40:35 | AJaeger | I'll send this out as an email... | |
| 16:46:59 | openstackgerrit | Andreas Jaeger proposed openstack/keystoneauth master: Cleanup py27 support https://review.opendev.org/720742 | |
| 16:52:30 | openstackgerrit | Merged openstack/shade master: Add Python3 victoria unit tests https://review.opendev.org/719022 | |
| 16:53:57 | smcginnis | AJaeger: Thanks for sending that. I've seen a few projects fix that over the last several months, but I'm sure there are probably several more that are still doing that wrong. | |
| 17:12:15 | openstackgerrit | Merged openstack/osc-lib master: Remove Babel from requirements https://review.opendev.org/717737 | |
| 17:34:40 | AJaeger | smcginnis: too many repos ;( | |
| 20:42:12 | openstackgerrit | Merged openstack/os-client-config master: Cleanup py27 support https://review.opendev.org/717609 | |
| 21:05:02 | AJaeger | smcginnis: coming back to our discussion, the project-team-guide does not talk about adding all dependencies, it only talks about the direct requirements, doesn't it? Updating it becomes really tricky in my experience: You increase one version, that needs further updates, that need further... | |
| 21:05:38 | AJaeger | To me it looks like we're not mastering lower-constraints yet... | |
| 21:05:58 | AJaeger | sorry, enough on that - need to leave now... | |
| 21:10:25 | smcginnis | AJaeger: Have a good weekend! | |
| 21:11:15 | smcginnis | Maybe we can invoke Doug for more background. The concepts behind this were probably lost due to not having openstack-specs anymore. Or at least some other good place to write it all down. | |
| 21:37:39 | openstackgerrit | Merged openstack/python-openstackclient master: Use unittest.mock instead of third party mock https://review.opendev.org/717410 | |
| #openstack-sdks - 2020-04-18 | |||
| 21:17:09 | openstackgerrit | Sean McGinnis proposed openstack/keystoneauth master: Use unittest.mock instead of third party mock https://review.opendev.org/720925 | |