Chris Jerdonek

> a function like run has to take the thing to run, and it also has to take its own arguments to configure how it runs it. Here's another option...

Okay, good to know. There's yet another hybrid pattern / approach you could use for all of these. Namely, rather than calling, say, `runner.run()` and putting the config options in...

Thanks for summarizing. You stated it well. Yeah, I'm familiar with the `functools.partial` approach required by `asyncio`. But it always feels unsatisfying and never natural. For example, each time you're...

A few thoughts that could be useful (after seeing the thread here: https://mail.python.org/pipermail/async-sig/2018-January/000437.html): First, I'd make separate the distinction of what "knobs" a library API might want to expose to...

> it outsources that to other engines and virtually no PDF engines produce reproducible PDF builds FYI, I know that [ReportLab](https://www.reportlab.com/), for one, provides this as an option. You can...

Hi @atugushev, what did you mean by this? > * split requirements files for hashable and non-hashable packages. Did you mean split the `requirements.in` file? Or did you mean split...

Thanks, @atugushev! However, won't splitting the `requirements.in` file into VCS and non-VCS requirements mean that the dependencies of the VCS requirements (which can be hashable) won't get the benefit of...

Okay, thanks a lot for confirming.

Maybe this could be implemented with an option that accepts a value, e.g. `--generate-hashes exact` vs. `all` (the current default). (I don't know off-hand if this approach could be done...

Suggestion: instead of the tricky logic in `is_invalid_params()`, is there any reason you couldn't do something like inspect the depth / level of the stack trace to see where the...