I think it’s time to wrap up this argument-by-analogy (though I agree it’s an appropriate analogy).
It sounds like in Petr’s view (to give the view an arbitrary name), an entry point executable generated by pip should not ever specify -L, and the person doing the install should decide whether to use -L or not.
In Barry’s view, the entry point metadata would specify that it wants -L and would get it unless the person installing somehow overrides it, under similar circumstances to how they’d override strict dependency requirements.[1]
Extending the analogy from “entry point script wrapper” to “however you configure application launch” is left as an exercise to the reader.
It seems to be a question merely of de-facto defaults. If we already had multiple tools that clearly handled each case, this wouldn’t even be a question, and there wouldn’t be such concern about libraries being “forced” to have lazy imports. But because different use cases most likely go through a single tool, they become conflicts.
(Here ends my attempt to sum up the point of the preceding, apparently off-topic, discussion. Here begins my opinions.)
This all actually makes me lean harder towards a command line option or environment variable, and continuing to default to “off”, which is the original proposal. But I would want to see clear messaging around what responsibilities you as the integrator (“end user”) are taking on by enabling the option. And they’re virtually all social responsibilities rather than technical ones:
- you don’t get to “call out” libraries in public because they don’t work yet
- you don’t get to demand fixes because they haven’t been made yet
- you don’t get to abuse maintainers because they haven’t made the fixes yet
- you do get to stop passing the option you chose to pass in yourself
I wish that was more hyperbolic, but I’ve seen it all happen. Fundamentally, I don’t think I have any concern with the PEP itself, but I hate the thought of adding more ways for people to justify being horrible to the volunteers who are writing the code that they’re using for free.
Possibly the only (bike-shedding) question I’d ask is could this be an -X option rather than its own command line option? Mainly just to make it even more obvious that you’re doing something weird. (Or does that break shebang processing because of multiple arguments? ISTR something about that, possibly in this thread already.)
[Edited to add]
More concretely on messaging, I think the PEP abstract and “how to teach this” could carry the main weight. The latter in particular should have examples of how to determine when an application is not behaving properly under lazy imports with an instruction to turn off the option.
In contrast, if we put out messages like “when things don’t work, you’ll just have to wait for the maintainer to release an update” then I think we’re actively encouraging the kind of behaviour I would rather reduce. Info on how to debug and patch/fix/workaround issues, and a suggestion to contribute the change, I think promotes more responsibility.
[Edited again to add]
And of course, this totally leaves open the possibility for an installation tool to choose to enable it via a shortcut (substitute “pip” and “script wrapper” if you like concrete examples, but I’m trying to stay general).
If a package developer explicitly says “when people run my script, I support lazy imports” then they deserve the feedback that comes from that.
It’s just that when someone goes “my webserver starts up faster when I enable this option, oh it broke, let me go shout at the Django developers,” it should be really obvious that they ought to be shouting at themself first.
-
And most likely by using a tool other than
pip, I would assume. ↩︎