Unified installer

[jstayco]

I apologize for the size of this in advance. Also, this is a draft PR because I do not have Windows available to me, therefore, my Windows work (for the python 3.10, tk, and git detection and installation portions) was best effort and 100% untested.

Setup.sh and setup.ps1 both work fine on macOS w/ Apple Silicon and Ubuntu.

Major Design Goals:
Unify and simplify the installation and running experience across all OSs and environments.

Minor design goals: Improve the documentation.

High Level Overview:
Setup.bat, setup.ps1, and setup.sh's purpose is to ensure that Python 3.10, Python Tk 3.10, and git are installed. They can then pass all provided arguments to launcher.py.

Launcher.py does all of the prework kohya_gui.py needs such as the pip installs, virtual environment creation and switching, downloading entirely new installs and upgrading existing installs. Launcher.py will then call kohya_gui.py with the appropriate arguments.

Kohya_gui.py now has the ability to load configuration files and has logging facilities to match the logging facilities in launcher.py. I have included a few sample debug statements in kohya_gui.py to mirror those found in your new debug.py file with the goal that you can remove your debug file and simply embed any debugging statements into kohya_ss and get text logs out of it.

---

Text Logs:
Text logs will abide by the verbosity level you set on calling any of the scripts. You will find text logs by default in $USERPROFILE/.kohya_ss/logs. Logs from launcher.py will be prepended with launcher_* while kohya_gui logs will be prepended with kohya_*. It is now possible to get easy debug log files from users provided the appropriate logging.debug, error, warning, and critical statements are utilized throughout kohya_ss.

---

Configuration Files:
Details are in README, but values are now loaded in this order across all of the scripts:

1. Command line values
2. Values found in $installation/install.yml (these values take priority over the other configurations)
3. Values found in $USERPROFILE/.kohya_ss/install_config.yml
4. Values found in $installation/config_files/installation/install_config.yml
5. Built-in script defaults.

---

Misc.
I also added a larger and more comprehensive .gitignore, added a .gitattributes to avoid line ending errors, improved the README to be more compact and readable, removed old scripts that the new ones replace (the old upgrade scripts, validate requirements, etc), converted project from setup.py (deprecated) to the newer pyproject.toml format.

Git is no longer a hard requirements as launcher.py will now attempt to download the latest release zip from the main stable branch if git doesn't work.

There's probably some more minor notes, but this was a large PR and I tried to be comprehensive about the changes in the README.

---

I also had to add these files in this branch because of import errors. Not sure the deal with that, but you can remove them if they are unnecessary of course.
library/merge_lycoris_gui.py
library/extract_lora_from_dylora_gui.py

[jstayco]

Also, for the branch conflicts?
Highly recommend using these files from this PR:
.gitattributes
.gitignore
README.md
kohya_gui.py
requirements.txt

And you can remove gui*, upgrade*, and any other setup, prework, or cleanup utilities that the new setup* files and launcher.py deal with now.

The setup.ps1 and setup.sh scripts are main entrypoints. Launcher.py can also be used for the more advanced users who don't need environment checks for python or for those dealing with containers. Launcher.py handles both building in and out of containers and running in and out of containers.

[jstayco]

I wasn't sure what information you wanted in the pyproject.toml file on these lines so I left them default values:

authors = [
    {name = "Your Name", email = "your.email@example.com"},
]

[bmaltais]

Hi @jstayco WOW, this is a lot to unpack for sure ;-) Lot's of work on this. Thank you for taking the time to do all this super work. I will test the windows part of the script as I don't use Linux. I can also test the MacOS part on my M1 Mac (I don't really use it anymore now that I mostly work from my AI PC).

I was working on integrating more logging in the current code base but I will park that intil your PR is merged as I don't think I will need those anymore... or might change how I am doing it to align with your PR solution.

[bmaltais]

Just tried running setup.ps1 and got atraceback from launcher.py about _log_gir:

(venv) PS D:\kohya_ss> .\setup.ps1
Git already installed.
Traceback (most recent call last):mpleted. (Number of bytes processed: 28315928)                                     ]
  File "D:\kohya_ss\launcher.py", line 1394, in <module>
    setattr(args, "log-dir", os.path.abspath(get_logs_dir(args)))
  File "D:\kohya_ss\launcher.py", line 1335, in get_logs_dir
    os.makedirs(_logs_dir, exist_ok=True)
  File "C:\Users\berna\AppData\Local\Programs\Python\Python310\lib\os.py", line 215, in makedirs
    makedirs(head, exist_ok=exist_ok)
  File "C:\Users\berna\AppData\Local\Programs\Python\Python310\lib\os.py", line 215, in makedirs
    makedirs(head, exist_ok=exist_ok)
  File "C:\Users\berna\AppData\Local\Programs\Python\Python310\lib\os.py", line 215, in makedirs
    makedirs(head, exist_ok=exist_ok)
  [Previous line repeated 1 more time]
  File "C:\Users\berna\AppData\Local\Programs\Python\Python310\lib\os.py", line 225, in makedirs
    mkdir(name, mode)

I made the code print wnat is inside _logs_dir and I can see the file path is not right: D:\kohya_ss\C:\Users\berna\.kohya_ss\logs

I suspect something is not properly creating the file path upstream

Trying to run the setup.bat file fail on the version of python installed. I check fo 3.10 but I have 3.10.9. I think the setup.bat file will be hard to make work properly.

I sort of fixed the issue by changind line 227 of setup.ps1 to: 'LogDir' = if ([Environment]::OSVersion.Platform -eq 'Win32NT') { ".kohya_ss\logs" } else { "$env:HOME/.kohya_ss/logs" }

[bmaltais]

Hummm... I got passed the issue. It ran the dependancy installation but I see it keep redoing setup all the time even after completing it the 1st time. I like the idea but I wonder if the whole setup process is not getting too big and complex for it's own good. I understand it is still work in progress but I am worried it might become very complex to maintain just the installer and launcher part.

[jstayco]

Hm. When I hard coded everything with $HOME it worked great, but I tried to have it detect Windows so LogDir would default to $USERPROFILE/.kohya_ss/logs on Windows and use $HOME on non-Windows. It works well on Ubuntu over here as-is.

And the batch file is really just a throwaway to be honest. It's a relic from the 80s. The real way is PowerShell or Bash and I've listed the setup.bat file as "legacy" in the README.

For your setup stuff? What you're seeing is launcher.py roll through all the pip stuff for validation of packages. Remember the scripts you have for package validation, setup stuff, etc? That's all in launcher.py now.

So....
(I'm not sure on WIndows, but all scripts can be launched as just *.py now on non-Windows. The files have #! lines and are checked in with execute bits enabled. You may still have to call it like python3.exe launcher.py on Windows)

Building a container and don't need it to run? launcher.py --setup-only
Your environment is good and you know it? launcher.py --no-setup
And these switches work on all scripts as well setup.ps1 -NoSetup will accomplish the same functionality.

And it's flexible enough for development purposes.
Have a local repo you're working on, but want to do a quick deployment and check it?
setup.ps1 -GitRepo ./ -Branch myDevBranch -Dir ../../myTest/folder
Have a remote repo to test?
setup.ps1 -Branch dev -Dir ../kohya_ss_devTest (You can use any remote repo here, I used it for my fork, but it defaults to the master branch and https://github.com/bmaltais/kohya_ss.git repo.

And what you're seeing as "redoing setup" isn't actually redoing setup. It's skipping all the things it already detects as good and running through the pip validation to ensure all packages are present. It's not actually redoing setup from scratch.

This installer is without question more complex than the stuff you previously had because it accomplishes a lot more and covers down on every single OS I could try to cover down on. The aims for operating systems/environments where I could get them were Linux, macOS, FreeBSD, Windows 10, and Windows 11 using native PowerShell, cygwin, or msys2. And I tried to code everything so you use PowerShell on Windows and you can use PowerShell or Bash on all the non-Windows operating systems.

[jstayco]

On further thought, I also check Python versions in launcher.py and kohya_gui.py (so they can be launched either through launcher.py or directly), so I've removed the check from setup.bat.

You can also remove debug_info.py I believe after this merge and just put in any smi-specific code into the debug_system_info() function in kohya_gui.py. I tried to give you a more operating system, CPU, and GPU manufacturer-agnostic check for info there.

I know this is a large PR, but I think it adds a ton of value for the cross platform story, consolidates functionality into launcher.py, and enables proper logging facilities and log files in launcher.py and kohya_gui.py (plus the rest of the program, I just didn't add logging statements passed kohya_gui.py in this PR).

[jstayco]

For your issue where the path doesn't work for LogDir, does this line fix the issue?

'LogDir'         = if ([Environment]::OSVersion.Platform -eq 'Win32NT') { "$env:USERPROFILE\.kohya_ss\logs" } else { "$env:HOME\.kohya_ss\logs" }

I'm thinking the handoff from setup.ps1 -> launcher.py isn't working quite right because of the backslashes on Windows.

[bmaltais]

I tried with the new line. WHen I start setup.ps1 it keep throwing an error about file permissions on the venv:

(venv) PS D:\kohya_ss> .\setup.ps1
Git already installed.
Logs will be stored in: C:\Users\berna\.kohya_ss\logs bytes processed: 28315928)                                     ]
Switching to virtual Python environment.
Error: [Errno 13] Permission denied: 'D:\\kohya_ss\\venv\\Scripts\\python.exe'
Installing python dependencies. This could take a long time as it downloads some large files.
Please be patient. It takes time for the requirements to be collected before showing Python package validation and installation progress.
Installing packages:  48%|████████████████████████████████████████████████████████████▍                                                                | 15/31 [00:31<00:33,  2.12s/package]

And the install keep running and take minutes to complete and this is not a really good user experience. Almost like it does not know the install is already done and keep running it over and over every time setup.ps1 is run.

After running it now gives this errpr:

Logs will be stored in: C:\Users\berna\.kohya_ss\logs
Traceback (most recent call last):
  File "D:\kohya_ss\kohya_gui.py", line 584, in <module>
    check_gpu_vram()
  File "D:\kohya_ss\kohya_gui.py", line 121, in check_gpu_vram
    gpu_vram = gpu_info[0][1].replace(' MiB', '')
IndexError: list index out of range
Traceback (most recent call last):
  File "D:\kohya_ss\launcher.py", line 1482, in <module>
(venv) PS D:\kohya_ss> 
  File "D:\kohya_ss\launcher.py", line 1322, in main
    launch_kohya_gui(args)
  File "D:\kohya_ss\launcher.py", line 1292, in launch_kohya_gui
    subprocess.run(cmd, check=True)
  File "C:\Users\berna\AppData\Local\Programs\Python\Python310\lib\subprocess.py", line 526, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['D:\\kohya_ss\\venv\\Scripts\\python.exe', 'D:\\kohya_ss\\kohya_gui.py', '--listen', '127.0.0.1', '--server-port', '7861']' returned non-zero exit status 1.

I'm wondering whether it might be more appropriate to maintain the current Windows setup while concentrating on creating a unified installer for Linux and Mac. Given that you don't use Windows, it would be challenging for you to verify the installer on that platform, and a significant number of users rely on the Windows scripts. At this point, I don't think it's feasible to shift the Windows side to the new solution.

I can allocate time to address installation issues, but this wasn't something I had initially anticipated.

What are your thoughts? Should the new installer primarily cater to non-Windows operating systems, with Windows remaining separate until better integration is possible? Perhaps we could retain the simpler setup.bat (which now supports both torch 1 and torch 2 optional installs) and gui.bat? As long as the updated kohya_gui.py accepts the same parameters as the original, the current gui.bat and gui.ps1 should still be compatible... and the users are grown used to run the UI with those, so removing them from the solution will cause irritants to the community.

Given the extensive modifications made to files unrelated to setup, thorough testing will be necessary. I'm concerned that this might also create problems for Windows users since you're unable to test that. Although the project originally focused on Windows, the PR introduces changes that facilitate support for non-Windows platforms, which I can't directly assist with. I appreciate the effort to include Linux and MacOS, but it must be done in a way that doesn't negatively affect Windows functionality. Currently, I feel that the setup solution is disadvantaging Windows, which is somewhat concerning.

It seems that striking a balance between Linux/Mac and Windows, while keeping things modular and avoiding cross-platform impacts, is essential. This is especially important considering I can't thoroughly test Linux and Mac, and you can't test Windows, which raises some concerns.

[jstayco]

Let me see what I can do about Windows. Maybe I can throw up a VM or something. I think it is still very much worth keeping the Windows stuff though because half the point was unifying the user experience. I didn't think it was very fair for me to make a fancier macOS/Linux setup script that had all these nice checks and logging facilities, but then Windows is left behind since I'm sure most of your users are on Windows. This line: Error: [Errno 13] Permission denied: 'D:\\kohya_ss\\venv\\Scripts\\python.exe' is no big deal. I'm checking permissions on the venv folder and Windows probably just doesn't like setting that one for whatever reason (but agree it still shouldn't surface an error outside of debug mode - I'll change that).

And the install keep running and take minutes to complete and this is not a really good user experience. Almost like it does not know the install is already done and keep running it over and over every time setup.ps1 is run.

This is because of the pip validation being done on every launcher.py run. That's where I was saying you can just run it with setup.ps1 -NoSetup or launcher.py --no-setup and it will skip everything and just switch to venv and launch kohya_gui.py right away. I have this as default behavior because I saw a lot of issues on your Github repo that would've been solved if the installation was self-healing. So it does that by default now. More advanced users can just configure and skip things as they desire.

I know this is a large PR and it took me some weeks to get here. That's why I put a draft PR for now because I knew there was no way I covered everything in the first attempt especially with Windows. I am very much convinced, however, this is the way to go. I am aware that removing scripts isn't always fun because change is change, but I made sure kohya_gui.py runs all of the same old arguments + the new log-dir and -file arguments for config file loading and custom log directory location (especially helpful to containers that might have different volume locations). As well, it simplifies the setup, launching, and maintenance of the program across all operating systems and unifies the experience completely.

Edit:
My thought process behind having it self-heal was to avoid having the easily-solvable issues pop up in your Github issues page. If you think the trade-off in startup time (for those that run it default without reading any docs or help messages) isn't worth it, maybe I could figure a way out to only run the pip validation stuff on the first run in a given install folder and then only run it after that if the user specifies either --repair or --update. Just let me know which direction you want me to head.

And every script has properly-formatted help messages:

launcher.py --help
get-help setup.ps1 -Full
setup.sh --help

And all of the options for all of the scripts and configuration files are noted in the README in the Configuration section.

[bmaltais]

Regarding the CONTRIBUTING.md I find it is focussed on the installer side and not around the overall project. Perhaps it should be renamed to something like CONTRIBUTING_Installer.md

[jstayco]

That's where you'll need to come in afterwards. It's focused on the installer because that's what I worked on so far. I'll need you to fill in similar high level overview for the logic passed kohya_gui.py. That's why I was calling it a starter kit earlier.

[jstayco]

On further inspection, I got tensorrt from a runpod dockerfile from the beginning of this effort. Therefore, I've removed the requirement entirely for now.

I was messing around with it to see if I could get it to kick, but it was adding 6Gb to my AMD system and that's just unnecessary complication and storage space as there are multiple components to install on a bare metal machine, so I'd have to add a whole module to handle just tensorRT. We can move that into the Nvidia docker image along with any other necessary installation components as needed if we find it's necessary.

I'm also going to hold off on a Linux requirements.txt file as it's not needed at this time. It would only be one or two lines. If that requirement grows down the road, it will be very easy to add it in since I already have that going for macOS. You would just make your requirements.txt file, then in the pip section where you see my "if macOS" lines? Copy/paste and change to " platform.system() == Linux".

[bmaltais]

Sound good.

Still fail on the last requirements.txt entry for some reason:

PS D:\kohya_test2> .\setup.bat --interactive
Launching D:\kohya_test2\setup.ps1.
Beginning main function.
Python 3.10 is already installed.
Git already installed.
VC Redist already installed.
Switching to launcher.py.


Logs will be stored in: D:\kohya_test2\logs
Beginning launcher.py.
Switching to virtual Python environment.
Checking for pip updates before Python operations.
Beginning kohya_ss dependencies installation.
Choose Torch version: (1) V1, (2) V2: 2
Installing torch and related packages. These download large models. Please have patience.
Installing torch (2.0.0+cu118): (1/3).. Done
Installing torchvision (0.15.1+cu118): (2/3).. Done
Installing https://github.com/C43H66N12O12S2/stable-diffusion-webui/releases/download/f/xformers-0.0.14.dev0-cp310-cp310-win_amd64.whl: (3/3).. Done
Please be patient. It may take time for the requirements to be collected before showing progress.
Installing <censored_local_path to maintain user privacy>: : 31/31 █████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████ 02:26/00:00
ERROR: Launcher.py had to exit due to an error during the main installation.
ERROR: [WinError 3] The system cannot find the path specified: 'D:\\kohya_test2\\venv\\Lib\\site-packages\\tensorrt\\libnvinfer_plugin.so.8' -> 'D:\\kohya_test2\\venv\\Lib\\site-packages\\tensorrt\\libnvinfer_plugin.so.7'
"PowerShell exited successfully."

Manually running pip install -r requirements.txt does not report any issues.

[bmaltais]

Just ran the latest pushed code and noticed xformers-0.0.14 is still installed instead of 0.0.17. Probably a small issue witht the v2 vs v1 requirements in python.

But the positive thing is that it installed fine with the recent updates.

[jstayco]

It's a bug in the way I'm comparing the variables with the introduction of the text file to track last used Torch version. I'm working through those now along with a few other minor bugs I found on the way.

[jstayco]

@bmaltais I think I fixed the Torch stuff to be a much better UX. Now it will remember your last used Torch version and not switch it until you specify otherwise via command line or configuration file. And when it does switch? It now properly brings xformers and other deps along with it.

And since I had a hard time figuring this logic issue out, I split up the torch operations into 3 functions to make it easier to handle: configure commands, uninstall packages, installation/repair.

While I was here I found that I hadn't touched the brew dependency install function since the beginning of the effort, so that has been brought into line with the pip experience with a progress bar and debug information.

I'm fairly sure I'm missing some macOS dependencies, but all the procedures work at this point. It'll be a challenge nailing all the dependency stuff for every OS. Windows is solidly nailed down of course, but macOS + Linux + containers will most likely take a bit until we get user feedback and wider testing.

Edit: Please note running launcher.py in interactive mode will trigger a Torch uninstall/reinstall every time to afford the user the ability to change it. If you'd like to see the behavior -t 2 will run in torch 2 mode, then omit the switch or use it again -t 2 and it will not trigger a reinstall, but if you follow these with a -t 1 it will trigger the reinstall and switch you over to Torch 1.

[bmaltais]

Tried the latest version and it appear to work very well.

[nhjydywd]

Hello, I'm running on linux and I encountered some issues during the installation of xformers. I think we should give up torch 1.x and directly install torch 2.0. Because when I use pip command to install xformers, it seems that this library only support torch 2.0.

[jstayco]

@nhjydywd Could you provide some more information, please? What issues did you encounter? If the issues are directly related to the installation of it, you can run these scripts with verbosity 3 and it will output a debug log in the logs folder.

I'm asking because I've been developing this mostly on Ubuntu and haven't run into issues installing that myself.

[jstayco]

@bmaltais Right now the repair option just force uninstalls Torch + deps and then reruns the pip upgrade/installs to catch any inconsistencies. But we now time stamp the last completed pip install/upgrade.

I was considering putting in some startup logic like "if we're in repair mode and last successful pip operation was > 2 weeks ago, let's just completely remake venv by deleting the folder and remaking it".

Thoughts? Is something like this useful or counter productive and we should just leave destructive stuff to manual commands?

[bmaltais]

@jstayco I think we should leave it to manual commands to keep things consistant from an experience point of view.

[jstayco]

Makes sense to me. In that case I think this is ready for wider testing and possibly merging into dev. I'll at least flip it to a real PR for review. If you find my documentation lacking or anything, let me know. But documentation is something I can improve after this is merged to be honest. There is already enough for a starter kit.

Lastly, I'd like to ask if I can get some limited permissions to the repository. My goals are: be able to assign installation-related issues to myself, close those issues as needed, and possibly dev write permissions if you're comfortable with that, so I can push fixes through ASAP since I'm expecting all of the bugs from all kinds of setups. If you are also comfortable with it, if you give me access to the Github secrets and workflows for this repo, I can start testing out automated Docker builds and publishing capabilities for you.

The last two aren't necessary of course, but it will save development time from bug reports to fixes and speed up the Docker capability development.

I know it's a big ask for permissions, so no pressure at all.

[jstayco]

Just be aware if you merge to dev there WILL be bugs. This is covering a wide area and there's just no way that I got everything 100% on the first attempt. So expect many bug reports and fixes. If and when you merge this, plan to keep it as it is extremely large and could become quite an issue to unwind.

For the conflicting files, I tried to rebase again and it doesn't look like it cleared them. I'm not sure about the dll's, but README, requirements.txt, and setup.bat should all be taken from my branch.

I think the Dockerfile may have gotten caught in my linter since I didn't touch that. You can discard that one.

[bmaltais]

OK, let's merge to dev and start to make small updates to fix issues.