Log file Viewer

[00:17:06] <buck2> ... how do I run the pip tests?

[00:21:17] <buck2> got it. nevermind :)

[03:37:16] <kevinverse> heyo

[03:37:22] <kevinverse> I have a quick question about pip

[03:37:24] <kevinverse> anyone have a min?

[03:40:38] <tomprince> kevinverse: Ask your question and stick around. When somebody has a chance, they'll answer.

[03:41:20] <kevinverse> I am trying to run `pip install [ziparchive]` into a tmpdir

[03:41:42] <kevinverse> ideally i just want a directory with the full unpacked contents of the zip

[03:41:54] <kevinverse> `pip install --build [tmpdir] [zipurl]` doesn't seem to work, neither does -t or --src or etc.

[03:43:06] <kevinverse> I could `pip install -d` and then just unpack it myself

[03:43:17] <kevinverse> but I would like to do it through pip if possible

[14:10:45] <alex-foo> we're writing a (yet another) packaging system and want to piggyback on PyPI for python packages -- it seems there are at least two places where dependencies are expressed - some packages have in the JSON API an info/requires list, and others rely on setup.py egg-info requires.txt -- is any of this documented?

[14:12:20] <alex-foo> also i've seen at least two python modules for working with pypi - pkgtools, pypiapi, neither of them seem to be working properly at present :/ is the code in pip suitable for reuse?

[14:14:21] <tomprince> Probably not as-is. If it was refactored to have an API and moved to https://github.com/pypa/packaging/ perhpas.

[14:14:41] <tomprince> What is your packaging system going to bring to the table?

[14:18:27] <alex-foo> tomprince: a load of in house requirements... a lot like Nix TBH

[14:18:59] <alex-foo> we are (obviously) unifying PyPI, CPAN, NPM, Ruby Gems, etc.

[14:19:18] <alex-foo> also do PyPI packages have any way of expressing non-PyPI dependencies? like GCC?

[14:21:12] <apollo13> no

[14:21:17] <apollo13> at least not currently

[14:21:26] <apollo13> I think there is a new metadata pep which covers that?

[14:23:00] <alex-foo> ok cool, i think we'd like to be a part of that - can you remember the name of the PEP?

[14:23:47] <DanielHolth> PEP 426

[17:17:08] <buck2> dstufft: the wrong-case scenario is tripping me up

[17:18:12] <buck2> do you support the scenario where lowercase dinner is requested, pypi has uppercase Dinner 2.0, and filesystem cache has lowercase dinner 1.0

[17:20:10] <buck2> at any rate, it looks like i'm going to need to refactor the PackageFinder.find_requirement method heavily

[17:20:29] <buck2> could i convince any of you all to take a first pass at it?

[17:20:49] <buck2> doesn't need to work, just give me the sketch of what you'd like to see. I'll do the rest.

[18:16:54] <tos9> There's no actual way to tell -U which packages you want to upgrade is there?

[18:17:32] <buck2> pip install --upgrade thatpackage ?

[18:17:44] <tos9> That upgrades any package pip encounters.

[18:17:50] <tdsmith> adding --no-deps will keep it from upgrading dependencies en route

[18:18:14] <tos9> tdsmith: yeah but it won't upgrade ones that are actually necessary :/

[18:18:26] <tos9> e.g., if the new version does >= someversion, it won't get upgraded

[18:18:26] <tdsmith> ¯\_(ツ)_/¯

[18:18:39] <tos9> but if it doesn't, it will still try to upgrade, even when it shouldn't.

[18:19:26] <buck2> --upgrade-minimallhy

[18:19:40] <tos9> is that actually a thin

[18:19:49] <buck2> no, it's a feature request from you :)

[18:20:01] <tos9> Oh, yeah :/.

[18:20:31] <buck2> tos9: if you *really* need this behavior, you'll have to add some scripting on top of pip i think

[18:32:15] <qwcode> buck2, tos9 for a "only if needed" upgrade, see https://pip.pypa.io/en/develop/user_guide.html#only-if-needed-recursive-upgrade

[18:32:51] <buck2> qwcode++

[18:33:38] <tdsmith> ooh

[18:33:47] <tos9> qwcode: Ah. Nice :). Thanks. Glad it's being considered as the default.

[18:34:57] <qwcode> my thinking is that "pip upgrade" would do "only if needed" by default, whereas "pip install --ugrade" would stay as is and be deprecated eventually

[18:35:24] <buck2> sounds good

[18:35:28] <qwcode> is there a more proper way to describe "only if needed"? I don't know?

[18:35:51] <buck2> with minimal change?

[18:36:02] <tos9> pip install --upgrade --conservative was what would have came to mind

[18:36:14] <qwcode> yea, conservative is good

[18:36:30] <buck2> probably still want a maximal option tho

[18:37:15] <qwcode> but with conservative being the default, then I guess "--recursive" becomes the opposite "pip upgrade --recursive"

[18:37:33] <buck2> sounds ok

[18:38:36] <buck2> qwcode: do you know the PackageFinder.find_requirement function?

[18:38:48] <buck2> i'm trying to get it to not hit http if there's an exact match in the filesystem

[18:38:59] <buck2> it's harder than it looked at first =/

[18:39:24] <qwcode> buck2, I fear answering this question... there's a black hole here... : )

[18:39:51] <buck2> this method seems to have 1e100 states

[18:39:55] <buck2> =/

[18:40:09] <qwcode> I've worked with it in the past... but it's not fresh in my mind right now... : )

[18:40:18] <buck2> my latest confusion: file:// gets sorted into url_locations rather than file_locations

[18:40:37] <buck2> otherwise i'd be done i think

[18:41:52] <buck2> qwcode: the conservative upgrade is recursive too, so --recursive might not make sense

[18:42:29] <buck2> maybe could make sense with proper doc

[18:42:32] <qwcode> buck2, yea, "exhaustive"? or maybe that kind of upgrade really shouldn't exist?

[18:43:30] <qwcode> "--latest-acceptable"

[18:43:46] <qwcode> I'm wondering if the right language exists in the OS packaging world, but I'm just not familiar enough

[18:48:08] <buck2> dist-upgrade would be the debian

[18:48:21] <buck2> maybe

[18:48:56] <buck2> it's certainly true that apt-get doesn't change more than it needs to

[18:50:27] <buck2> under apt-get you'd need to explicitly list all the packages you feel like upgrading

[18:50:34] <buck2> dist-upgrade equivalent to listing all the things

[18:55:31] <tomprince> apt-get update will also upgrade things. I think dist-upgrade is for when multiple packages need to be upgrade in tandem (maybe with circular dependencies, or the like)

[20:36:59] <buck2> i have to say this stuff is much better covered than i expected

[20:37:04] <buck2> test-wise

[23:11:18] <buck2> what are "dependency links" ?