re pull/158

[timmypidashev]

Summary

The python port of Breath was coming along fairly well, until the installation process was realized to be quite cumbersome when relying on the python subprocess module for most of the work. That is, until the plumbum module was recommended by @MilkyDeveloper, which I quite like. Well, the reason for this discussion is the complexity a python project brings to the table that I would like to address, as well as clarify any blurry lines to speed up development and minimize project iterations, such as the one that is going to happen over the next couple of days.

Breath as a pip package

Firstly, porting the Breath installer to python brings with it several opportunities, such the ability to package Breath into a PyPi package. While early discussions discussed the possibility of a trans-piled python executable, I think the best approach would be leveraging the built-in python module runtime, with a shebang at the top of __init__.py(#!/usr/bin/env) to allow the user to run the python module without python -m or the like. Additionally, a more permanent solution would be to provide an entry point in the setuptools setup.py:

setup(
    # your other arguments ..
    entry_points={
        'console_scripts': [
            'breath = breath:main_function'
        ]
    }
)

Overall this abstraction alone really defeats the point of trans-piling or freezing the python code, unless the installer aimed to not require python installed on the system or the like.

Project structure

Talking up the setuptools module for creating python packages makes this discussion rather confusing if the project structure is not discussed. Currently, this is the idea in my head:

.
├── setup.cfg
├── setup.py
├── requirements.txt
├── @kernel
├── breath/bin
└── breath

One with keen eyes will notice that this project is likely not using setuptools, but pbr. The reason for this is that apart from being almost identical in features to setuptools, pbr also provides metadata like version, descriptions and the like on install(a handy feature), and provides an easy way of adding an entry-point. On top of that, it is configured nicely through setup.cfg, though setup.py is still required. Also note I have presumed file locations of the bin directory and @kernel(these are mere suggestions, and really dont affect anything.) I have also left out folders that dont affect the project's core, such as docs, readme's, etc. These need no mention.

Finally

Recently a really neat module has been brought to attention, plumbum. This can handle anything from shell commands, command piping, all the way to command-line parsing, the best part being it is all done in an elegant fashion. The last discussion I would like to point out is the idea of revolving the internal guts of breath to work close with this module, as it can handle all breath needs very nicely.
With it most modules being used right now can be stripped, such as argparse.

Anyways, technical details aside: python + plumb + pbr + good project structure + organized work and documentation = a well built breath installer. At least these are my thoughts, and prior to beginning a new iteration of an already fairly experimental fork, I thought it would be a good idea to flesh out any ideas and concepts this implementation of breath should look like.

[RodBarnes]

I'm not a python coder but have extensive coding experience in many other languages, both compiled and interpreted. What is the intent in moving to python? Is it to provide better packaging than a bash script provides? Not challenging the idea, only would like to better understand the direction and intended result.

[MilkyDeveloper]

I wouldn't say there's any barrier when almost all enterprise-support distros (Ubuntu, Fedora, CentOS, Alpine, RHEL). We could also just make a self-extracting archive or something like that using this since Powershell is a static binary.

And, besides, Powershell isn't used as a "shell", especially on Linux.

[RodBarnes]

@MilkyDeveloper Love the rant. :-) Totally agree. I'm completely neutral on tools and platforms. I pick the one that works for what I need to do. That's all.

But, there is something to be said for the simplicity of Bash-on-Linux since both are pipe-oriented. I do wonder about bringing PS with its OOP over to Linux and using it there. I haven't done that so don't have any actual experience but it makes me wonder...

[timmypidashev]

About the rant: I am the kind of person who appreciates and tries to use all types of platforms, programs, stacks, whatever buzzwords people use nowadays. The dotnet framework is actually quite nice, although I have to admit I have yet to do any serious programming with c# yet. Powershell on the other hand I just have not grown used to, but I do agree it is more favorable in comparison to some of the crazy commands bash has.
@RodBarnes I totally agree with your last reply. Really the main reason I even brought up moving to a different framework is that the configuration was a nightmare. I think packaging breath with python to be used as the end user interface would be nice, and we can use both ps and bash depending on the user choice, though it would be tedious to maintain both at the same time.
@MilkyDeveloper oop is nice, but I really appreciate the way you implemented the breath install currently. Prior to me finding this project, I had not done much shell scripting other than automated linux installs, and the data oriented structure you got going on is really quite nice.

[timmypidashev]

So with all the above in mind, I will try my best to write a nice cli configurator in python, maybe polish the current one and strip what is not needed, and essentially just have the python installation pass a dictionary of environment variables to the core installer. Another cool thing we can integrate is nice error catching with python's subprocess stderr instead of setting the bash installer to quit on any mistake, which can allow for some flexibility. Maybe write in some simple library functions that can allow for custom headless intallations. Overall I really like the idea of keeping the breath core, as I admit I was getting scared of how to properly port those commands and the structure to python. Bash just makes more sense there.

[MilkyDeveloper]

I would agree with that. At this point, Breath's bash installer is using set -e (exit on errors) and is tolerant of lots of use-cases on the supported distros.