How to package executables

[Adam R. Maxwell]

> On Jul 20, 2020, at 17:08 , Norbert Preining <norbert at preining.info> wrote:
> 
> But we might and up with many of the __main__.py files if python module
> based programs proliferate. And they will, because Python is designed to
> be a PITA and force people to strange naming requirements. (Been there,
> done that, always asked myself why Python is popular).

Because it's more readable than Perl, Norbert (but so is line
noise, for that matter) :P.

> 
>> other hand, this is breaking new ground -- there are no __*__.py files
>> in TL now. I am automatically leery. 
> 
> Of course it would be possible to merge the __init__.py and __main__.py
> into one file, and use that as ultimate source and binary. This is what
> i would suggests.

Yes, and it can still be loaded as a module. I've never seen a
module with all code directly in the __init__.py file; it's
a sentinel to tell Python that a directory is a package, as I
understand. I could be wrong, as it's been years since I
set up my own module for distribution, and I recall it being kind of
confusing. Maybe Python 3 changes things.

> Splitting functionality into modules is only useful if there will be an
> actual use of the module.

Agreed. A single file makes more sense for TL, and you can still put
a __main__ function in it and make it executable. I put everything
into a file called spix.py, but my testing failed since I don't have
python3 installed. File here, if it's helpful as a starting point:

https://www.dropbox.com/s/rwj7m4yi20rf1bb/spix.py?dl=0

> But then, it is Python, and object encapsulation is based on file level
> and file naming *and* directory naming, how retro.

Well, for search path and module naming, but you can also get
around that, IIRC. I think of object encapsulation as your code,
and you can put classes in whatever filename(s) you want, as I'm
sure you know.

-- 
Adam