A suggestion on the update scheme/policy/methodology/strategy, etc. regarding loaders. #6104
leomaxwell973
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
So, during the course of using textgen webui and troubleshooting issues, and going back and forth between extensions and projects etc. etc. some of us may use the updater quite often.
One thing that doesn't take long to realize, is the loaders are mostly linked to github repos and do not follow the usual rules in pip, as in, checking if it's up to date and skipping, in particular, instead viewing it as an deliberate command to download, similar to --force-reinstall --no-cache.
This can be very time consuming for no reason, especially during troubleshooting. Of course, noticing the problem and understanding how pip works, I have disabled them to download automatically, but there is no middle ground I'm aware of ... yet, at least afaik.
A thought that occurs to me, is how there are set categories for downloads, A for general install updates, B(+A or B-#x) for extensions, not to mention a git head reset, and well, there's surly room in there for 1 more, for loaders or github specific updates that aren't fully integrated into pip yes? this way, there is a constant reminder for people in my situation, or it could be the new default, that when you run the updater, it's a stand alone/segregated update series.
This seems like a very solid and sound idea to me because : loaders, unless you are doing some specific projects or work, are very niche to be touched during moding, mostly its the general python files going back and forth constantly (though quickly due to caching and not downloading every single time necessarily), so, with loaders being touched less and needing to be downloaded less, and thus , making the strategic move to avoid their downloads taking up the most time for no reason, sounds like a very wise plan, simply by taking all the github and other exclusive links and adding them to a new requirements file, and only running that file through UI options, at least, if option x,y,or z is chosen etc.; AND even if you were working on something that touched loaders constantly, you could also make this menu accommodate, yet, still, by having it be able to target specific loaders instead of all.
I did a quick search for frequently updated etc. and didn't see anything, so apologize if this has been brought up before, but, search said it hasn't so...
anyway, that was my eureka thought for the day, cheers!
Beta Was this translation helpful? Give feedback.
All reactions