Absolutely no offense taken. It was just an interesting learning experience being in the position of trying to explain my use case and being confronted with helpful questions which, although well-intentioned, came across as expecting me to justify my choices. I’ll certainly be more careful in future about how I talk to people offering use cases as a result.
One thing I know I tend to do is use such “have you tried X, Y or Z” approaches to avoid having to flat-out say “no” to a request. I think that’s a fairly natural thing to do - we wouldn’t be contributing to open source if we didn’t want to help people get their jobs done, so saying “no” to a proposal or feature request goes against that instinct. But I think that sometimes we have to just accept that a decision needs to be made, or an opinion needs to be stated, and we don’t always have to justify ourselves.
One other thought on this point. If I did have shared code, I could just put it in a lib directory[1] alongside my scripts, and then do import lib.foo. Python adds the script directory to sys.path, after all, and this is precisely what it’s good for.
Personally, I might make lib a “real” project and publish it on PyPI, just because I can, and as a packaging expert that seems logical to me. But for many sysadmins, DBAs and data analysts of my acquaintance, that would be a massive step, and the simple lib directory is a much more appropriate solution for their situation.
But this is now way off topic. Let’s go back to simpler subjects like bikeshedding over whether to use Requirements: or Dependencies: or something else 
You don’t even need an
__init__.py, thanks to implicit namespace packages ↩︎