Log file Viewer

[00:32:58] <toad_polo> "skered" (https://matrix.to/#/@freenode_skered:matrix.org): How would you know?

[00:33:53] <toad_polo> "jaraco" (https://matrix.to/#/@freenode_jaraco:matrix.org): I think the idea that setuptools would adopt distutils like that is part of what the PEP should cover, rather than presenting it as a fait accompli.

[00:34:56] <toad_polo> Though I suppose vendoring distutils and not exposing it to end users is orthogonal to that.

[00:43:18] <skered> toad_polo: I'd like to guess some meta data is kept locally for installed packages, if package A is trying to upgrade and that version is beyond the required range halt/stop/dont-allow that upgrade?

[00:44:33] <skered> That is beyond the range of another installed package that is.

[00:44:34] <toad_polo> I don't think there's any way to know that your dependencies will break after an upgrade.

[00:45:12] <toad_polo> The closest thing is to opt in to the new resolver, which will determine if there are declared version conflicts.

[00:45:19] <skered> toad_polo: No I mean upgrading a dependency not the lead package.

[00:45:43] <toad_polo> I don't see how that changes anything.

[00:46:00] <skered> So if package A need back B <3.0 and I try to upgrade B and that upgrade is upgrading to >3 that upgrade is now allowed.

[00:46:33] <skered> I think I just saw that warning message about the new resolver too.

[00:46:44] <toad_polo> Correct, unless you use the new resolver, I think.

[00:47:11] <skered> Let me play around with that. Thanks.

[00:47:37] <toad_polo> Though TBH "<3.0" version pins are usually a lie anyway, or at least unlikely to be useful.

[00:50:45] <skered> That might be the case but I have seen cases where I upgrade something and it breaks another.

[00:53:03] <toad_polo> Yeah that'll keep happening.

[00:53:44] <toad_polo> Version numbers just don't and probably can't convey enough information to handle that.

[00:54:51] <skered> Looks like the new resolver in 20.2 still allows the upgrade.

[00:56:04] <toad_polo> Your best bet is lock files (like pip-compile generates) in addition to your standard non-locked dependencies, and frequently testing upgrading the whole lock file.

[00:57:25] <skered> Can pip tell me or is there an non-pip way of knowing the deps for a given package?

[00:59:31] <skered> I know pipdeptree can provides this but not pip directly?

[01:13:20] <tos9> skered: (there's no real standard of how dependencies are declared. an arbitrary package can declare it in theory in arbitrary ways)

[01:13:30] <tos9> skered: (ways that pipdeptree can't know about either)

[01:13:50] <tos9> but for a narrow but widespread view of the world yes you can know what the dependencies are

[02:09:24] <skered> My current goal is to upgrade as much as possible and keep pip-check from giving errors.

[06:02:08] <pradyunsg> tos9: uhm, pipdeptree shows installed packages' trees, which is deterministic.

[06:04:28] <pradyunsg> skered: As @toad_polo noted -- to do what you want to do, a good approach would be to use lockfiles like the ones that pip-tools (specifically pip-compile) creates.

[12:27:23] <tos9> pradyunsg: a package installer doesn't have to put metadata in a place pip (and pipdeptree) would find it, no