Replies: 5 comments
-
Line 179 in os.system(f"sudo cat ./src/ashpk_core.py ./src/distros/{distro}/ashpk.py > /mnt/.snapshots/ash/ash") 👆 Overall, this method of concatenating the core file with the distro-specific file is not ideal because it does not enforce a common API. I also recommend using a tool like pyright to catch some of the low-hanging bugs you have right now, and this isn't really doable when you're referencing functions from another file with no importing. I think you can improve things by setting up some basic core classes that can be subclassed by distro. For example, it would be better to do something like this: src/ashpk_core.pyclass AshPkCore(object):
# [...] your core functions could stay mostly as-is
def install(self, snapshot, pkg):
# [...]
self.install_package(snapshot, pkg)
# [...]
def install_live(self, pkg):
# [...]
self.install_package_live(tmp, pkg)
# [...]
# [...] distro-specific classes should override these:
def install_package(self, snapshot, pkg):
pass
def install_package_live(self, snapshot, pkg):
pass src/distros/arch/ashpk.pyfrom src.ashpk_core import AshPkCore
class AshPkArch(AshPkCore):
# The core functions are inherited from the base class.
# Here, you are subclassing the core and defining only the distro-specifics.
def install_package(self, snapshot, pkg):
try:
subprocess.run(f"chroot /.snapshots/rootfs/snapshot-chr{snapshot} pacman -S {pkg} --overwrite '/var/*'", shell=True, check=True)
except subprocess.CalledProcessError as e:
print(f"F: Install failed and changes discarded: {e.output}.")
sys.exit(1)
def install_package_live(self, tmp, pkg):
try:
subprocess.run(f"chroot /.snapshots/rootfs/snapshot-{tmp} pacman -Sy --overwrite \\* --noconfirm {pkg} >/dev/null 2>&1", shell=True, check=True)
print("Done!")
except subprocess.CalledProcessError as e:
print(f"F: Live install failed and changes discarded: {e.output}.")
sys.exit(1)
# [...] src/distros/debian/ashpk.pyfrom src.ashpk_core import AshPkCore
class AshPkDebian(AshPkCore):
# [...]
def install_package(self, snapshot, pkg):
try:
subprocess.run(f"chroot /.snapshots/rootfs/snapshot-chr{snapshot} apt-get install -f -y {pkg}", shell=True, check=True) ### --overwrite '/var/*'
except subprocess.CalledProcessError as e:
print(f"F: Install failed and changes discarded: {e.output}.")
sys.exit(1)
def install_package_live(self, tmp, pkg):
try:
subprocess.run(f"chroot /.snapshots/rootfs/snapshot-{tmp} apt-get install -y {pkg} >/dev/null 2>&1", shell=True, check=True) ### --overwrite \\*
print("Done!")
except subprocess.CalledProcessError as e:
print(f"F: Live install failed and changes discarded: {e.output}.")
sys.exit(1)
# [...] Then there is no need to concat these files together. Line 179 in os.system(f"sudo cp ./src/distros/{distro}/ashpk.py /mnt/.snapshots/ash/ash") and you would get more meaningful output out of This concept could be applied to all of the components listed. Everything just needs a core API and implementation details separated. |
Beta Was this translation helpful? Give feedback.
-
@duhdugg Thanks for the write-up. The reason I went with simply concatenating was to keep ash as a single file. It was brought up here: https://discord.com/channels/484200829230776321/484200829230776323/1012190933149827124 Now, I think it might be inevitable to let go of this single file executable ideal as Ash gets bigger. I'm interested to start a brainstorm. Also, let me know what you think of profile folder. YAML etc can definitely be used to standardize the approach. What we have right now is rudimentary as it is a just a POC to get things done and out the door! |
Beta Was this translation helpful? Give feedback.
-
I think we should move towards a proper configuration language. We should try to keep as much stuff as possible generalized and cut down the distribution-specific code to a minimum - even when handling these profiles. |
Beta Was this translation helpful? Give feedback.
-
Currently, this is structure of codebase:
Let's put it on paper... formulate and have a birds-view of the new config management we're talking about. @CuBeRJAN or anyone else: Can you make a design file (using draw.io or whatever tool) and make a PR so we can get the ball rolling? |
Beta Was this translation helpful? Give feedback.
-
@duhdugg I have made a bit of change to the project now. I'm still not using classes. I'm not opposed to it and as you mentioned it just needs a few modifications that are quite trivial. We might use classes if need arises more over time. Please feel free to push PRs etc. |
Beta Was this translation helpful? Give feedback.
-
Hi everyone,
I would like to open a discussion about complexity of AshOS and how best to manage and organize it. We have at least 5 varying components to deal with (depicted in a Venn diagram below):
Right now, 3, 4, and 5 are simply conf files under profiles folder, but I think as the number of supported components grows, a better way to organize becomes absolutely necessary.
I would like to hear ideas from our community. Thank you!
Beta Was this translation helpful? Give feedback.
All reactions