-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow symlinks creation during model install rather than copying the model #5780
Conversation
b9a4054
to
453c688
Compare
Is there a reason not to do it this way? |
@brandonrising - Have you tested? If this works, it'd make sense to me. |
Only tested some on a mac so far. Planning on testing on windows/linux today, but it works really well on a mac for standard generations. |
453c688
to
5686287
Compare
Symlinks require elevated permissions on windows. There needs to be a check for this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of comments.
-
As noted above, symlinks won’t work on Windows unless the user is running as an Admin or has enabled Developer mode. So you should catch an exception and revert to physical copying if the call fails.
-
As an alternative to doing the symlinking, there is an unused option named
inplace
that can be passed to the install methods. If this is set, then local model file is not moved or copied; instead its current path is simply registered with the model configuration record. It looks like I simply neglected to expose this feature to the API, but I could do this. What do you think?
|
7f2705b
to
b8ef940
Compare
Not a fan of platform-specific behaviours and special handling. You shouldn't need to access the db to see model paths, you can just open the model manager tab right? We can easily expose the paths there if we haven't already. |
Yeah that's fair. I didn't run into any issues running it on windows, but maybe I've just always been running it in admin mode. Honestly, in-place installs like @lstein suggested would resolve the issues I'm having anyway. I could switch this PR to do that instead. |
I'd much prefer an in-place install option. It probably shouldn't be the default, because it shifts the responsibility of managing the model files to the user. We can add a checkbox to the MM UI, with a blurb explaining the feature. How does in-place interact with the diffusers conversion cache? What if my in-place model is on a different drive from my root models dir - say, a mounted network drive or external drive - is that going to tank performance of the JIT model conversion? |
That said, I don't think we need this for v4. We have a lot of changes to model installation happening, maybe we should work towards this for a minor release after we are confident in the model installation process. |
Closing in favor of in place installs |
What type of PR is this? (check all applicable)
Have you discussed this change with the InvokeAI team?
Have you updated all relevant documentation?
Description
This PR allows users to elect into using symlinks for model installs rather than doubling the disk space usage of the models they're installing