Hi, I've read about the new offpunk refactoring. I _really_ like the way
it's described in the post, great job!

I'm just a bit confused about the actual problem though, why can't the
individual pieces just be exported as "dumb" executables, with a nice
`#!/usr/bin/python3` shebang on top?

Just put them in $PATH and bam, they're nice simple individual
executables, no fuss whatsoever.

That could also allow third-party reimplementations, were there the
need. That sounds pretty UNIX-y to me.

Am I missing something?

On Mon, Oct 02, 2023 at 12:17:54 +0000, Riteo Siuga wrote:
> I'm just a bit confused about the actual problem though, why can't the
> individual pieces just be exported as "dumb" executables, with a nice
> `#!/usr/bin/python3` shebang on top?

I think they're not just executable programs, but a mixture of program
and library in each file, so the problem is with `import`ing modules. I
would have thought that the best way would be to make one library file,
which is installed to the default library location, and then each
interface is one file in $PATH which imports the library. Maybe that's
not possible in Python.

On Mon Oct 2, 2023 at 2:27 PM CEST, phoebos wrote:
> I think they're not just executable programs, but a mixture of program
> and library in each file, so the problem is with `import`ing modules. I
> would have thought that the best way would be to make one library file,
> which is installed to the default library location, and then each
> interface is one file in $PATH which imports the library. Maybe that's
> not possible in Python.

I see, I get the problem now. IMO all "subpart" tool invokations should
be done through the system, as if done from a shell, instead of being
`import`ed, since they should already be executable. This should also
improve UNIX-ness as then nothing should stop us from having an ansicat
implementation made in C or any other language such as, why not, Hare.

Other than that, I don't see a better solution than making everything a
module, which is indeed not ideal.

On 23/10/02 01:00, Riteo Siuga wrote:
>On Mon Oct 2, 2023 at 2:27 PM CEST, phoebos wrote:
>> I think they're not just executable programs, but a mixture of program
>> and library in each file, so the problem is with `import`ing modules. I
>> would have thought that the best way would be to make one library file,
>> which is installed to the default library location, and then each
>> interface is one file in $PATH which imports the library. Maybe that's
>> not possible in Python.
>
>I see, I get the problem now. IMO all "subpart" tool invokations should
>be done through the system, as if done from a shell, instead of being
>`import`ed, since they should already be executable. This should also
>improve UNIX-ness as then nothing should stop us from having an ansicat
>implementation made in C or any other language such as, why not, Hare.

That was the original idea behind the refactoring but I came to realise 
that it is a bit harder and not always efficient.

By importing, I can make simple python functions which are usable and 
which can returns complex objects (like dictionnaries and lists).

I hope, in the long term, to be able to have completely separate 
binaries. But it is harder than expected.
>
>Other than that, I don't see a better solution than making everything a
>module, which is indeed not ideal.
>

-- 
Ploum - Lionel Dricot
Blog: https://www.ploum.net
Livres: https://ploum.net/livres.html

Am Mon, Oct 02, 2023 at 12:17:54PM +0000 schrieb Riteo Siuga:
>I'm just a bit confused about the actual problem though, why can't the
>individual pieces just be exported as "dumb" executables, with a nice
>`#!/usr/bin/python3` shebang on top?
>
>Just put them in $PATH and bam, they're nice simple individual
>executables, no fuss whatsoever.
As said before, you can’t because of `import`s. This works seamlessly after a 
`git clone` because all of the files are in the same directory.

A solution, if python packaging is too much annoying, is to bypass it. Install 
all of your python files in /usr/libexec/offpunk, and add symlinks to the ones 
you want publicly available in /usr/bin.

Since all your python files will be in the same directory, `import`s will work, 
and since there are symlinks in your $PATH, you’ll be able to run them quite 
simply.

A plain Makefile with `install` instructions would do the trick.

Only downside is, other projects won’t be able to import your libraries, unless 
they ship it, which as a system administrator I do not recommend.

BISOUS
Hoël