Updated install.sh
As I am using one PC for multiple Klipper instances, it was "difficult" to install the config without having a few problems.
By adding the function, the user can choose a custom folder name. He can always decline if he has only one instance and needs to go the standard route.
I used the following scheme for naming as kiauh does the same: Services as moonraker & klipper: klipper-xyz config-data: xyz_data
I can change the function to ask to put in the full folder name. I hope this addition is helpful to you.
I have tested it on my machine and it worked so far.
Thanks you very much for this PR! I just discussed with someone about this :)
However it might needs a little bit more work as I think it break the backup feature of the script. Don't forget this script is also called everytime an update is done by moonraker. Do you have tested this part ?
So creating a backup works actually fine. But should also be tested by someone else. I will wait for the next update and check it out again.
I will have to check the updating part the next time an update is available.
But I think you are referring to the fact that anytime the install.sh script is called, there is no custom folder name available and it will stop or got the standard route right?
So creating a backup works actually fine. But should also be tested by someone else. I will wait for the next update and check it out again.
I will have to check the updating part the next time an update is available.
But I think you are referring to the fact that anytime the install.sh script is called, there is no custom folder name available and it will stop or got the standard route right?
Yes, in fact I'm referring to how it will handle the multiple printer thing: when you click the update button on one of the printers WebUi, moonraker will update the repo (doing a git pull), then will call the install script for this specific printer instance. However there is some things coming to my mind:
- Fluidd/Mainsail will not allow you to answer questions at this time (so everything should be automatic or will fail)
- The repo will be updated and so are all the symlinks on all the instances. So you will have all the printer updated at once, but the backup on only one of the instances
This is most definitely true. It needs to be implemented into the install script or another way.
Another way is to have the install script get parameters from a local file? It's only two variables that need to be "imported".
By importing those the install.sh can stay the same and be updated however you/we want to.
Another way is to have the install script get parameters from a local file? It's only two variables that need to be "imported".
This is indeed what I currently have in mind. You could add a .CONFIG entry to the .gitignore to avoid tracking it when created directly in the the Klippain repository path.
Then in the install.sh script use ~/printer_data/current/config/path >> .CONFIG every time it's run to install a new printer.
Finally, when updating from one of the WebUI, make the script read this file and backup all the folders from all the machines one by one.
I think this is a way to make it work properly. What do you think about it? :)
Another way is to have the install script get parameters from a local file? It's only two variables that need to be "imported".
This is indeed what I currently have in mind. You could add a
.CONFIGentry to the .gitignore to avoid tracking it when created directly in the the Klippain repository path.Then in the
install.shscript use~/printer_data/current/config/path >> .CONFIGevery time it's run to install a new printer. Finally, when updating from one of the WebUI, make the script read this file and backup all the folders from all the machines one by one.I think this is a way to make it work properly. What do you think about it? :)
Have to read into it. But seems like a proper solution to me!
The .CONFIG could be also used for future purposes.
Schematics:
install.shlooks if there is a.CONFIGfile
-
if not it wil ask you if you need a custom path or just the nomal way
-
if yes it get the custom path way and just do an update in that case
The .CONFIG should be created either way, custom or non-custom.
For installing/ updating multiple instances at once we need to implement a loop do you have another way in mind?
Schematics:
install.shlooks if there is a.CONFIGfile
- if not it wil ask you if you need a custom path or just the nomal way
- if yes it get the custom path way and just do an update in that case
The
.CONFIGshould be created either way, custom or non-custom.For installing/ updating multiple instances at once we need to implement a loop do you have another way in mind?
This is exactly how I would do it :) So that's good, we share the same idea! And yes a loop is probably the way to go!
Ok, so I was thinking about how to do this PR efficiently.
I currently have a bug in the install script when the folder is not empty during the first install: it just install Klippain on top of the old user config and keep all the files side by side. It's working as files are replaced, but not clean. So I will need to fix it in the next release.
Also, you may not be aware, but I'm involved in a KIAUH issue where we plan to add support for user plugins and Klippain is one of them (see: https://github.com/th33xitus/kiauh/issues/330).
So in order to get things running easily, I plan to split the install.sh script in two:
install.sh: an interactive script to proceed with the installation of Klippain. This will be called only once manually of from KIAUH. Ideally, the user interface should match a little bit more to the KIAUH style as I find it really good and it would help to get an uniform workflow when installing from KIAUH. This script could also install numpy and input shaper needs, the gcode_shell_command plugin, auto Z calibration plugin, ERCF system, etc...update.sh: automatic (no user interaction needed) script run by the moonraker update manager to proceed with backups, etc...
Yeah I have seen that bug on the first install of one of my machines. It can leave quite a mess behind when updating, since adding/changing new variables will make the cfg no to work.
Not related to this pull, but be careful changing z-offset settings in the releases. At some point z-offset was changed from commented to uncommented. Messed up the z height and drove the nozzle throug the flex plate. Just a note to give other useres a warning when updating.
install.sh and update.sh would be even better. Integrating it into the kiauh worklfow could open the possibelity to grap machine locations automaticly and update/maintaining everything through kiauh.
what about putting the z-offset in the printer.cfg so it can be updated by klipper and it is sure that it is even correct after upgrade since it is in a #*# at the end of the config?
📌 This pull request has been marked as stale because it has not had activity in the past 30 days. Please update the PR or comment to keep it active. Otherwise, this will be closed in 14 days. We appreciate your contribution!
📌 This pull request has been marked as stale because it has not had activity in the past 30 days. Please update the PR or comment to keep it active. Otherwise, this will be closed in 14 days. We appreciate your contribution!
📌 This pull request has been marked as stale because it has not had activity in the past 30 days. Please update the PR or comment to keep it active. Otherwise, this will be closed in 14 days. We appreciate your contribution!
📌 This pull request has been marked as stale because it has not had activity in the past 30 days. Please update the PR or comment to keep it active. Otherwise, this will be closed in 14 days. We appreciate your contribution!
📌 This pull request has been marked as stale because it has not had activity in the past 30 days. Please update the PR or comment to keep it active. Otherwise, this will be closed in 14 days. We appreciate your contribution!
📌 This pull request has been marked as stale because it has not had activity in the past 30 days. Please update the PR or comment to keep it active. Otherwise, this will be closed in 14 days. We appreciate your contribution!
📌 This pull request has been marked as stale because it has not had activity in the past 30 days. Please update the PR or comment to keep it active. Otherwise, this will be closed in 14 days. We appreciate your contribution!