Build to a binary

[flohw]

Hello @boi4,

I wanted to know if it would be possible to build a binary from the sources ? Even if the binary still requires the two major dependencies exiftool and libheif.

It would ease usage in scripts.

Also, just a side question : I looked at the generated dynwalls.service file and I find all my environment variables dumped into. Is it possible to dump only the required ones ?

Thank you for your script. I will test it more tomorrow 🙂

[boi4]

Hi @flohw ,
thanks for your interest in the project :D

1. It should be possible to create a single executable python file by joining all python files in the dynwalls folder and removing some import statements/fixing some possible namespace issues. A quick google search for projects that can create a whole binary (which has python included, so you wouldn't even need python installed) didn't lead to anything promising, maybe something like http://www.pyinstaller.org/ ?
2. Yes, this happens here: https://github.com/boi4/dynwalls/blob/master/dynwalls/systemd.py#L32 . It's a rather ugly hack that I used to circumvent some problems with specific files not being found (exiftool, heif-convert), b.c. the PATH variable is missing, I think. An easy fix would be to add something like

join(f"Environment=\"{k}={v}\"" for (k,v) in os.environ.items() if "%" not in v and k in ["PATH", ...]))

at https://github.com/boi4/dynwalls/blob/master/dynwalls/systemd.py#L34.

If you want you can check out which Environment variables are necessary for (2.) and maybe add some script which generates the single executable for (1.) and create a pull request. If you are new to python I can help you.

Cheers, Jan

[flohw]

Thank you for the anwser. I will make a PR for the second issue, I can handle that 🙂

I will take a look to create a binary. Maybe we can create github actions after that. Never tried this feature 🙂

[boi4]

Sounds cool 👍 never tried it myself either 😄

[boi4]

I thought about it and think that creating a python package (https://packaging.python.org/tutorials/packaging-projects/) might be a solution to the problem.
If the package contains a dynwalls script that calls python3 dynwalls and we set it up correctly, then installing the package will place it into /usr/bin and you can use the tool like any other program when scripting.
Furthermore, one could upload the package to pypi.org and make it available via pip3 install dynwalls. What do you think?

[flohw]

I am not a python developer (PHP instead) but have some basics of the environment and ecosystem and wanted to learn about it for years. Maybe this project is a good start 🙂

I will look into this packaging process as it looks like it solves both issues: use dynwalls as a binary and make it available to pip.

Is it still required to run python3 or pip3 as python 3 is now the default version and python 2 is legacy-sort-of? I always prefer the more up-to-date commands and use the default one provided by the system. I think it's preferable as the system will use the default one the user has less effort to do to identify potential error. (that's just a side question 😉)

[boi4]

I am not that familiar with the whole packaging process either, so it's a win-win: we learn more about the packaging and it gets easier to install and use the tool. 🎉

About your side question: As far as I know, python2 support has been officially dropped earlier this year and at least on my Arch-Linux Laptop, the python command invokes python3. However it's the same problem as with using new programming language features (if you use the old way of doing things your software is compatible with both new and old versions). So sticking to python3 in scripts will create (at least today) less problems, as , say someone running Debian-stable is still able to use it without python2 being accidentally run. So I would stick to python3 in this project^^