-
-
Notifications
You must be signed in to change notification settings - Fork 344
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
Multi-match 'find', allow 'as' for Ships and GameData #3064
Conversation
With
This is of course always a result of wrong metadata (see KSP-CKAN/NetKAN#7919 (comment) for this case), and thus probably a good thing so we get reports about it. But I think we should display a different error message in this case. For example, we could try to scan for duplicate files before installation. |
Good idea, if netkan.exe prints a warning, then we can catch and fix all of these before the new client is released. |
|
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.
While I can't 100% certify this has no bugs, it does seem to work, and I hope we are going to find possible unexpected behaviours in the pre-release 😄
Oh, I think we'll find unexpected behaviors in the next netkan pass... 🤞 |
Background
CKAN supports multiple properties for specifying which files to install (only one is allowed per modue):
install[].file
- A path to a file or folder, starting from the ZIP rootinstall[].find
- A partial path to a folder, or file ifinstall[].find_matches_files
istrue
install[].find_regexp
- A regular expression matching a folder, or file ifinstall[].find_matches_files
istrue
The
install[].as
property can be used to install a folder under a different name.Motivation
The implementation of
find
andfind_regexp
is kind of a hack; it relies on converting them to afile
value based on the contents of a ZIP file. This creates a number of problems and limitations, detailed under the next section heading. (It has also created bugs historically, see #2120 for one of my earliest fixes.)ModuleInstaller
has somestatic
functions that require aModuleInstallDescriptor
parameter (or one of its properties, related to the previous paragraph), which is a classic indication that encapsulation has been violated by putting those functions in the wrong class.As long as we're doing a pre-release for v1.28.0 anyway, why not rip-and-replace another big core piece of functionality?
Problems and limitations
find_regexp
is only allowed to match once, so setting it to"\\.craft$"
will only install one file even if there are several, and which one is chosen is unpredictable (and the same is true but less conspicuous forfind
)as
arbitrarily isn't allowed forShips
orGameData
, despite this being useful (e.g., you can put aShips
folder intoShips/VAB
)find
andfind_regexp
on a specific ZIP means that when the ZIP changes, the validity of the metadata can change along with it (see Fix CST100Starliner install NetKAN#7945 for a netkan that was valid until it wasn't)find
andfind_regexp
arbitrarily only match (containing) folders unless you setinstall[].find_matches_files
totrue
ModuleInstallDescriptor.DefaultInstallStanza
requires aZipFile
parameter to work, because it is implemented in terms offind
(which should be nobody else's business) and therefore needs to callConvertFindToFile
, which needs the ZIPChanges
ModuleInstallDescriptor.ConvertFindToFile
is deleted 😂;find
andfind_regexp
are now supported as first-class concepts alongsidefile
, all of which now flow into a single shared compiledRegex
object initialized according to their particular quirksModuleInstallDescriptor.DefaultInstallStanza
no longer needs a ZIP file to figure itself outRegex
objects on the fly in several spotsModuleInstaller.FindInstallableFiles
that takes aModuleInstallDescriptor
param is now a method ofModuleInstallDescriptor
ModuleInstallDescriptor.IsWanted
is nowprivate
because it is an implementation detail of this classModuleInstaller.TransformOutputName
is now a method ofModuleInstallDescriptor
, rewritten to no longer work only withfile
GameData
orShips
can now be renamed in-passing viainstall[].as
, just like any other folderMissions
will be removed from the path ifinstall[].as
isn't specified, just likeGameData
orShips
find_matches_files
no longer does anything; files and folders are both always matched (I can try to restore this if we need it, but it just gets in the way from what I've seen)Now this will work:
And this will match all craft files: