How to package executables

[Takuto ASAKURA]

Hi Adam,

sorry for break into the discussion, but may I ask why you want to put
your Python script into TeX Live from the first place?
Why not a repository for the Python world such as PyPI?

For instance in PyPI, I could find a number of packages related to TeX/LaTeX:

	https://pypi.org/search/?q=tex+live

Of course some (perhaps most) of them require TeX Live (or other TeX distribution)
to utilize their features. I guess they don't handle installation of TeX
distributions themselves, but the users are responsible to install TeX.
As far as I know, this way is typical for TeX-related projects which are
not directly inside the TeX world (CTAN).

Since TeX Live do not include Python interpreter and also not require the
interpreter, there is no guarantee that an user of TeX Live have a Python
interpreter in their environment. Thus, TeX Live users who can use your
Python script are somewhat limited.

I imagine that, for the general Python users (and who also use TeX Live),
it might be just fine if your python package can be installed via pip, conda,
or whatever in the Python world. This way, I think you can be much
comfortable with the typical Python manner, without thinking about naming
issue and so on.

Best,
Takuto

> On 2020/07/21, at 13:29, Norbert Preining <norbert at preining.info> wrote:
> 
> Hi Adam,
> 
> funny discussion that is ;-)
> 
>> Because it's more readable than Perl, Norbert (but so is line
>> noise, for that matter) :P.
> 
> Kind of disagree, even after long long time or writing Python code.
> 
>> 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
> 
> No, there are lots of modules that put all the code into __init__,
> and yes, it is still the sentinel so it might be empty, too.
> Nothing has changed in this respect.
> 
>> 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
> 
> That is what I normally do.
> 
>> 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:
> 
> Nearly there, only two changes where necessary:
> 	import argparse
> was dropped, and two occurrences of
> 	spix.XXXXXX
> need to be replaced simply with
> 	XXXXXX
> 
> spix.compiletex -> compiletex
> spix.SpixError -> SpixError
> 
> That's it.
> 
>> Well, for search path and module naming, but you can also get
>> around that, IIRC. I think of object encapsulation as your code,
> 
> Yes, of course, you **can** get around it, but it is a huge pain in the
> butt. Trying to import not module files from outside the CWD is eg
> a huge pain, something like
> 	import XXX from .foo.bar
> etc will throw off Python(3).
> 
> So yes, as with any turing complete programming language with a minimal
> level of introspection, you can do whatever you want. It is just - first
> shoot yourself 20 times and then give up.
> 
> I know, Pythonistas will come after me and tell me what they always do
> 	You are not doing it the Python way!
> 	Use proper modules!
> And that is one of the reasons I despise Python. I don't want to get
> forced into a specific way of doing things. It should be a
> recommendation, but not forced upon us.
> 
> Anyway, that is all off topic ranting.
> 
> Best
> 
> Norbert
> 
> --
> PREINING Norbert                              https://www.preining.info
> Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13