WedWonder: Scripts and Modules

[DL Neil]

On 12/09/19 10:59 AM, Cameron Simpson wrote:
> On 12Sep2019 08:24, DL Neil <PythonList at DancesWithMice.info> wrote:
>> In this day-and-age do you have a script in live/production-use, which 
>> is also a module? What is the justification/use case?
> 
> Many. Many many.
> 
> 1: Many of my modules run their unit tests if invoked as the main 
> programme.

I used to do this, but now prefer to keep tests in separate modules - 
and separate directories.


> 2: Several modules are their own utility programme. I've got a heap of 
> these - anything that provides useful access to something can often be 
> usefully used from the command line.

This is an very interesting idea - you're way ahead of me on this!

Would it be fair to describe these as more Python for systems 
programming/system administration, than an application for (simple) users?
(what other kind is there???)


> Consider: if you write a package, would it have a __main__.py?
> 
> Well, if the answer is ever "yes" then the same applies to ordinary 
> modules, simple enough to not be worth splitting onto a package.

May not properly appreciate this point...


> So, yes, for me this is really really common.
> 
> Even for my current client project, which is largely a package, several 
> of the individual modules within the package have their own main 
> programmes for testing and for various utility tasks dealing solely with 
> that particular subsystem. There's an overarching shell script to set up 
> the environment and then do various things from the command line, and it 
> directly invokes particular modules for some operations that act only on 
> one subsystem.

Interesting!

Gives me pause for thought: perhaps I lean too heavily on putting 
'stuff' in the test routines (and view the application from that 
'direction' too often).

Multiple entry-point systems seem relatively unusual these days - 
perhaps a natural flow-on effect of the rise of gui- and menu-based systems?

With one client, over the years, we've developed a number of (basically) 
statistical analyses. Each analysis was born from a separate project. 
Each lives in its own directory (tree). There are some common modules 
held in a separate 'utility' library/package/directory. Whilst it has 
been suggested, the idea of an "overarching" menu-type top-level 
controller/distributor has never risen up the ranks of the "backlog" 
(sensible criticism: the money would be better spent on other 
priorities) - they (or at least the older ones) are quite happy to 
'drop' to the command line and type the required command+args. I think 
that's the closest I come to what you have described. (out of interest) 
Would you characterise it as a common project structure?

-- 
Regards =dn