Log file Viewer

[15:25:43] <pombreda> :D

[15:30:30] <pombreda> tos9: pradyunsg: ok, so only pip can fully parse requirements files correctly, since in end there are essentially a list of command line options for pip.

[15:30:30] <pombreda> with that said, I think that there is a mostly stable core that is worthy of having in some library:

[15:30:30] <pombreda> - the parts supported by the "Requirement" proper which is already handled by packaging.requirements

[15:30:30] <pombreda> - the hashes

[15:30:37] <pombreda> the rest could be pip-specific alright

[15:32:58] <pombreda> pradyunsg: there could be a way where this would return a list of "things" that could be :

[15:32:58] <pombreda> 1. plain lines of texts for things that are not "supported" or known

[15:32:58] <pombreda> 2. packaging Requirement

[15:32:58] <pombreda> 3. some new Requirement-like object with hashes

[15:33:27] <pombreda> pip would know what to do with plain text things and other could ignore that

[15:33:51] <pombreda> everyone could happily consume the results

[15:35:14] <pombreda> And if you add a function to dump to text the packaging.requirements.Requirement and a new packaging.requirements.RequirementWithHashes classes, then you could effectively load and dump back, round tripping things if needed

[15:36:05] <pradyunsg> pombreda: Look at parse_requirements, and (specifically) ParsedLine -- in req_file.py -- I think that's a good overall "structure" to do things.

[15:36:25] <pombreda> exactly

[15:36:39] <pradyunsg> :)

[15:39:13] <pradyunsg> the main point of coupling is build_parser, and while I understand what you mean by "plain lines of text", I'm not a 100% sure *how* you'd create that.

[15:50:35] <pombreda> well, if the base would be that code, then "plain lines of text" in the refactored code could be the pip options: https://github.com/pypa/pip/blob/cf418d7290342129fb4b687d3566cf9cdc94a2ca/src/pip/_internal/req/req_file.py#L302

[15:51:14] <pombreda> e.g. if this is not a requirement "logical" line (which may be several physical lines) then juts yield that as is

[15:51:42] <pombreda> and a pip parser would invoke the parser AND do its special stuffs on these

[15:55:24] <pombreda> pradyunsg: I had not paid attention to that build_parser ... it is using optparse :D

[15:57:21] <pombreda> may be the thing is too entangled... and it feels like having a parser forked from pip and not readily reusable by pip may be much simpler

[17:37:22] <pradyunsg> pombreda: ¯\_(ツ)_/¯

[19:44:31] <jwodder> One of my test suites has just started failing with the new setuptools 49.2.0 because setuptools claims I'm importing distutils before it and is generating a warning. None of my code uses distutils. How do I figure out what module is importing distutils?

[19:44:38] <jwodder> I've tried setting PYTHONVERSBOSE=1, but I don't see how to get the required information from the resulting logs.

[19:44:44] <jwodder> (Yes, I can ignore the warning, and I'm doing that for now, but I'd like to find what's causing it for my own edification.)

[20:12:11] <jwodder> Never mind; I was able to figure it out by adding "1/0" to the distutils source (in a Docker container, so I didn't wreck anything permanent).