PMXBOT Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Wednesday the 8th of April, 2020

(Back to #pypa-dev overview) (Back to channel listing) (Animate logs)
[08:42:37] <travis-ci> pypa/pip#15559 (master - bd912cf : Paul Moore): The build passed.
[08:42:37] <travis-ci> Change view : https://github.com/pypa/pip/compare/451f5d9f37a1...bd912cf0de62
[08:42:37] <travis-ci> Build details : https://travis-ci.org/pypa/pip/builds/672410251
[09:02:49] <travis-ci> pypa/pip#15561 (master - 327a315 : Xavier Fernandez): The build passed.
[09:02:49] <travis-ci> Change view : https://github.com/pypa/pip/compare/bd912cf0de62...327a31536ff7
[09:02:49] <travis-ci> Build details : https://travis-ci.org/pypa/pip/builds/672416778
[12:56:41] <travis-ci> pypa/packaging#899 (master - 61672bf : Pradyun Gedam): The build passed.
[12:56:41] <travis-ci> Change view : https://github.com/pypa/packaging/compare/9731c00837b8...61672bf9f507
[12:56:41] <travis-ci> Build details : https://travis-ci.org/pypa/packaging/builds/672497474
[13:30:48] <devesh> Hey folks, wanted to gain some understanding of the --prefer-binary flag
[13:31:04] <pradyunsg> devesh: o/
[13:31:18] <pradyunsg> devesh: if you have any questions, go ahead and ask. :)
[13:31:19] <devesh> pradyusng: \o
[13:31:59] <devesh> Yes, so If I understand correclty, --only-binary just downloads the wheel for a package
[13:32:09] <devesh> --no-binary downloads the source dist for a package
[13:32:43] <devesh> --only-binary and --no-binary can applies to one package, all the packages or a set of package
[13:34:05] <pradyunsg> Yes, that is all correct.
[13:34:33] <devesh> So in a requirement file, how will they look like
[13:34:41] <devesh> pkgA
[13:34:49] <devesh> let me use dpaste
[13:35:28] <devesh> http://dpaste.com/04BAE37 something like this?
[13:36:05] <pradyunsg> devesh: yea, though I think most folks put their options on top-of-the-file.
[13:36:28] <devesh> Okay so these options can be defined once, or multiple times
[13:36:54] <devesh> and the values are added over, so both are global options in a way?
[13:54:53] <devesh> pradyunsg: And how does --prefer-binary differs in how we can define it in the general, or in requirements.txt
[16:20:28] <sumanah> di_codes: thanks for your comment just now on metadata validation https://github.com/pypa/warehouse/issues/194#issuecomment-611051587 . Is there someplace I should have already looked for a summary of what Warehouse requires?
[16:20:41] <sumanah> I hate to cause anyone to do redundant work.
[16:20:44] <pradyunsg> @di: ^
[16:22:44] <PSFSlack> <di> sumanah: Warehouse requires everything marked as "required" in the metadata specifications. It's not documented anywhere besides the specs & that file (I think that would have been your hypothetical "Upload API" PEP)
[16:22:53] <sumanah> right
[16:22:58] <sumanah> ok
[16:23:46] <sumanah> I will dig into this more later; thanks again for the links
[16:23:54] <pradyunsg> From https://packaging.python.org/specifications/core-metadata/... The required fields are: `Metadata-Version`, `Name`, `Version`. All the other fields are optional.
[16:23:58] <pradyunsg> whoop.
[16:24:08] <pradyunsg> sumanah: for when you come back ^
[16:30:44] <devesh> pradyunsg: \o
[16:33:38] <techalchemy> pradyunsg, thanks for tagging me on the metadata discussion
[16:33:52] <pradyunsg> techalchemy: :)
[16:33:55] <pradyunsg> devesh: o/
[16:33:55] <techalchemy> i have been semi-aware of the work TP was doing but didn't realize brett had gotten so involved in it
[16:34:25] <techalchemy> I have like 20 tabs open since i meant to send him a PR back in like, november, about licensing
[16:35:03] <devesh> Hi pradyunsg: So --prefer-binary will be an option applicable to all listed package names in the requirements.txt right
[16:35:04] <techalchemy> never got around to it though, hopefully he read my mind and did waht i would have wanted anyway
[16:35:10] <devesh> Since it's doesn't take an argument
[16:35:39] <techalchemy> devesh, is that different from the current behavior?
[16:36:02] <devesh> techalchemy: Actually I should have given the context :)
[16:36:26] <devesh> I was writing a PR to add --prefer-binary to requirements.txt, so wanted to understand how it behaves
[16:36:34] <devesh> The current docs are pretty thin on it
[16:36:38] <techalchemy> oh you mean like, in the actual file
[16:36:46] <techalchemy> interesting!
[16:37:12] <pradyunsg> devesh: yep.
[16:37:50] <devesh> Yes techalchemy, https://pip.pypa.io/en/stable/reference/pip_install/#requirements-file-format lists --no-binary and --only-binary, but not --prefix-binary
[16:38:29] <devesh> thanks pradyunsg, and how does --prefer-binary interact with --no-binary and --only-binary?
[16:38:33] <techalchemy> devesh, how does that differ from passing nothing though
[16:39:24] <devesh> techalchemy: passing nothing to which option?
[16:39:29] <techalchemy> as far as I understood, pip already prefers binary distributions if they are available
[16:40:00] <devesh> yes techalchemy, but these options allow you to override that behaviour afaik
[16:40:05] <pradyunsg> techalchemy: --prefer-binary makes pip prefer wheels from older versions, even if an sdist is available for a newer version/
[16:40:17] <techalchemy> pradyunsg, *yikes*
[16:40:56] <techalchemy> nothing about that command name suggests that you'll prefer binaries *at the cost of not getting the latest version*
[16:40:59] <pradyunsg> techalchemy: why the "yikes"?
[16:41:20] <pradyunsg> ah, well, it's documented well-ish I think. :P
[16:41:26] <devesh> pradyunsg: So if I have --prefer-binary, --no-binary=:all: , and one package in requirements.txt , what's the behavopur
[16:41:44] <techalchemy> yeah but documenting an unintuitive command isn't an excuse for making it unintuitive :p
[16:42:02] <techalchemy> --only-binary seems like the one that would only ever let you get a binary even if it's older :|
[16:42:19] <techalchemy> --prefer-binary seems like it should prefer the binary version if it exists, but otherwise let you have the sdist
[16:42:49] <pradyunsg> devesh: it'll install the sdist. --no/only-binary filter out packages; --prefer-binary changes the ordering how preferable the packages are.
[16:42:57] <devesh> FYI the PR for --prefer-binary https://github.com/pypa/pip/pull/5370
[16:43:57] <pradyunsg> ^ see, a nice clean PR. :P
[16:44:11] <techalchemy> adding a file format preference doesn't suggest anything to me about the fact i'm now going to have outdated packages on my system
[16:44:19] <techalchemy> no matter how clean the pr is
[16:44:42] <techalchemy> maybe ei8fdb has thoughts
[16:44:53] <pradyunsg> well, that's precisely why it's an opt-in flag.
[16:44:57] <devesh> okay pradyunsg: So --prefer-binary is the sorting order, and this sorting order is wheels before sdists per package I think
[16:45:06] <pradyunsg> devesh: yup.
[16:45:47] <pradyunsg> techalchemy: the docstring of the option is "Prefer older binary packages over newer source packages."
[16:45:54] <devesh> Okay, I thought the PR was as simple as adding a line, seems like it's a bit more :)
[16:47:58] <techalchemy> pradyunsg, opt in flags still should be intuitive
[16:48:17] <techalchemy> adding tons of confusing flags still makes your software confusing, even if they are all optional
[16:48:33] <devesh> Hi techalchemy: I am planning to improve the document a bit as well in another PR
[16:48:35] <pradyunsg> techalchemy: have a better name for the flag?
[16:48:56] <pradyunsg> since I think your concern mainly stems from the name.
[16:48:59] <techalchemy> pradyunsg, 100
[16:49:06] <techalchemy> 100% from the name yes, let me read the use case
[16:50:10] <devesh> pradyunsg: So in terms of porting it to requirements.txt, I have made changes, and added tests similar to the original pr but on requirements.txt
[16:50:24] <devesh> Should that be enough? Or are there other cases I should check on
[16:50:43] <devesh> The PR is https://github.com/pypa/pip/pull/7996
[17:03:26] <pradyunsg> techalchemy: a gentle nudge. :)
[17:03:58] <techalchemy> pradyunsg, what about --always-prefery-binary :p
[17:05:14] <devesh> How do you generally rename an option? Keep both of them for some time, showing deprecated in front of one, and then remove the older?
[17:05:16] <pradyunsg> techalchemy: that makes it seem even more strongly that it's some redundant variant of --only-binary.
[17:05:40] <pradyunsg> devesh: we haven't done that in... forever, but yes, that's how we'd do it if we do it.
[17:06:35] <devesh> I think making a mirror of this flag called --prefer-sdists might be a good option too?
[17:06:55] <pradyunsg> devesh: no... that's basically --no-binary.
[17:07:52] <pradyunsg> since you always have an sdist is expected to be compatible with all potential systems (at least from the package index+pip interaction PoV).
[17:08:09] <pradyunsg> s/you always have//
[17:08:59] <techalchemy> pradyunsg, --always-prefer-binary seems less like --only-binary than '--prefer-binary' to me
[17:09:04] <pradyunsg> if there's an sdist on a newer version, pip will prefer that to an older wheel by default. There's no benefit to having a flag that doesn't satisfy any usecase.
[17:09:26] <pradyunsg> ^ devesh
[17:10:01] <techalchemy> it has not just 1 word different but also an additional word and the word means it will *always* prefer a binary package if possible, the thing that isn't IMO conveyed by the current command
[17:10:15] <devesh> pradyunsg: Is that because wheels might not be compatible with certain platforms, but sdists are almost always compatible?
[17:10:24] <techalchemy> not that it's the best or ideal command but just what i came up with quickly
[17:11:05] <pradyunsg> devesh: yep; all sdists are assumed to be compatible with the system, when getting stuff from the index.
[17:11:33] <devesh> Yeah, I don't remember if you touched on this yesterday? Maybe you did
[17:11:39] <pradyunsg> devesh: other than data-python-requires and data-yanked, which tell pip to not use it. :P
[17:12:03] <pradyunsg> devesh: I did, but very briefly. :)
[17:12:24] <pradyunsg> devesh: there was a lot to cover, so breadth took priority over depth. :)
[17:12:37] <devesh> yes, btw there is a release at the end of this month right?
[17:13:46] <devesh> true, depth is only achieve by "diving" into the code
[17:13:57] <pradyunsg> devesh: there's supposed to be, if I handle the responsibility properly. :P
[17:14:48] <devesh> Yes I see you are the release manager. I am not sure if I can help in any way towards a release?
[17:15:01] <devesh> Or any committer per se
[17:15:08] <pradyunsg> devesh: not sure.
[17:16:42] <devesh> no worries. I guess the PRs will start to be selectively merged as well before the release right, so as to not cause any surprises?
[17:18:05] <devesh> Ohh, I see it here: https://pip.pypa.io/en/latest/development/release-process/
[19:24:06] <techalchemy> god i have just no idea why windows failures dont appear in azure test results
[19:24:14] <techalchemy> the builds fail but nothing indicates what went wrong
[19:33:30] <sumanah> hey techalchemy - do you need a rubber duck to help figure out the Windows test failures in Azure?
[19:44:21] <sumanah> also techalchemy I hope you ate some lunch of some kind
[22:32:32] <travis-ci> pypa/twine#1357 (master - f7402e0 : Brian Rutledge): The build passed.
[22:32:32] <travis-ci> Change view : https://github.com/pypa/twine/compare/5482d6877df0cd90545c4708e5abe13b359f8a08...f7402e0d2e1c1e6ecde61dc8bcba515b807a48a0
[22:32:32] <travis-ci> Build details : https://travis-ci.org/pypa/twine/builds/672731792
[22:41:18] <travis-ci> pypa/pip#15571 (master - 327a315 : Xavier Fernandez): The build passed.
[22:41:18] <travis-ci> Change view : https://github.com/pypa/pip/compare/bd912cf0de62d7bed920ed6d794acb4e907cb782...327a31536ff71b99e5aa454bd325b3daf75b666d
[22:41:18] <travis-ci> Build details : https://travis-ci.org/pypa/pip/builds/672725539