Log file Viewer
#pypa logs for Saturday the 11th of July, 2020
[06:44:38] <pombreda> pradyunsg: as discussed before we are responsible adults, and we will copy and fork that pip code as needed.
[10:06:23] <pombreda> we are missing a library (a packaging function?) that can can simply read a requirements file, expose all its content in a nice models that one can mutate and update and simply write back as a requirements file
[10:08:07] <pombreda> this proves surprisingly difficult for the general case (the easy one is easy, but to handle every cases and hashes it seems weirdly hard to find an existing lib) ... or may be I am just crass at finding things
[12:04:29] <tos9> exposing the contents as a bunch of python objects is effectively saying "pip should make requirements.txt's format public and promise to stabilize more of it" (and pip not wanting to do that)
[12:04:44] <tos9> otherwise you can never really rely on what those objects look like any more than you can rely on what the requirements file looks like
[12:16:06] <pombreda> tos9: one can write by hand and parse mechanically requirement files to make sense of them. So it does not matter whether this is a good or bad idea. I need it for my tools: either there is a place that exists and that I can reuse. Or I will write the code :)
[12:17:28] <pombreda> pip non-api has been stable enough for me so far, and I will fork it as needed if that's what I need :)
[12:18:45] <pombreda> or may the approach would be: pip requirements are problematic, so let's not use them at all?
[19:01:50] <tos9> pombreda: I have never seen a correct requirements.txt parser personally (ever), including the one currently in e.g. pip-tools
[19:02:10] <tos9> As far as I know the ansewr from pip is "don't do that" -- if you do of course no one can stop you, but adding a function to packaging definitely seems like the wrong message, which is what I was responding to
[19:02:56] <tos9> (a function would imply that parsing requirements.txt files is supported, and yeah, as far as I know, it isn't.)
[19:50:37] <pradyunsg> tos9, pombreda: My suggestion for improving the "requirements.txt handling" situation is... let's refactor pip's code and then move it into an independent library.
[20:15:26] <tos9> pradyunsg: are there plans to do that for the current requirements.txt? I thought the "have a public way to specify dependencies that pip also reads" plan was requirements.txt v2 (or pipfile or whatever ends up being that)
[20:16:26] <pradyunsg> tos9: that's 100% a better way to do things -- I'm getting a little tired of "we'll design a new thing that'll solve the problem" approach to solving problems tho. :)