How to package executables
Adam R. Maxwell
amaxwell at mac.com
Tue Jul 21 05:40:36 CEST 2020
> 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:
> 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.
More information about the tex-live