This repository has been archived by the owner on Apr 17, 2024. It is now read-only.
re pull/158 #178
timmypidashev
started this conversation in
Ideas
re pull/158
#178
Replies: 1 comment 16 replies
-
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. |
Beta Was this translation helpful? Give feedback.
16 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
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 theplumbum
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 withoutpython -m
or the like. Additionally, a more permanent solution would be to provide an entry point in the setuptoolssetup.py
: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.
Beta Was this translation helpful? Give feedback.
All reactions