Hi Simon, thank you for the answer. > I believe the rejection to be correct
OK, and please understand me - I'm happy to go on but wanted that rationale to be well defined and intentional. So if it comes back as a hard dependency, or you want it for this or any other reason - there is no hard blocker against it as far as I've seen and we are happy to re-evaluate then. > As to the topic of fabric as an alternative, paramiko is a dependency of > fabric, thus bringing us back here. I didn't even want to suggest fabric, as I understand it is the older variant of the same. This was more about "if fabric would already be in main, then we should aim to let it go when moving to invoke" but that was not the case. > python-invoke package does have unit tests now ... This makes me believe this specific rationale may be outdated. Yes, that old reasoning is no more valid. You'd still want some kind of autopkgtest so that changes in dependencies are also tested. As you know in the simplest form run the same unit tests again, and maybe a real use case if not too hard to construct. When this comes back as MIR - adding autopkgtest is likely the first thing one will call out. --- To close out and to be even more clear. Having things in main without much purpose on their own but as dependency of something else is absolutely okay. If you still want it to go to main (e.g. if it eases maintenance a lot - I do not know how hard and frequent that pkg is in regard to having delta) you can just edit the rationale, make it explicit and clear that you know and say something like (based on your text): """ While it is only a recommends, upstream paramiko has removed the optional dependency and switched to a hard depends with version 4.0.0. This change is described by the upstream changelog https://github.com/paramiko/paramiko/blob/8697158113/sites/www/changelog.rst#L13 This may cause breakage in the future and we want to be prepared. We evaluated the callsites, all appear to use paramiko.SSHClient, and none of the paramiko.config parser, we should still be fine without invoke as well as of paramiko-4.0.0, the import excepts are still in place. For now we should be fine without invoke (as-is) but to follow the dependency change by upstream we want to promote it to main So for now, it looks we're fine without invoke. To be prepared and match upstream handling of that dependency we want to raise the dependency from a suggests to a recommends (as Debian has it) and it might become a full dependency down the road. """ With that there - clearly showing it is neither an accident nor not- caring, but intentional - we would be happy to pick up the review process again. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2138736 Title: [MIR] python-invoke (paramiko dependency) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-invoke/+bug/2138736/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
