unable to open KARs saved beneath absent (e.g. third party) modules
This isn't an issue in 2.1, since apple-extensions is loaded by all OSes in 2.1, but on trunk apple-extensions is now only loaded by macs. Because of this, KARs saved on a mac on trunk cannot be opened by linux or windows trunk -- the module-dependency checking code requires apple-extensions to be present first.
On a related note, a user emailed me a kar that used 3rd party modules today, and I can't open it through normal means because Kepler wants these module dependencies satisfied first.
The best solution isn't clear to me yet, an additional strictness level, that doesn't require module dependencies be satisfied to attempt to open the kar? Or it may be more streamlined to simply warn and offer to attempt to open without the module dependencies satisfied on each relevant open attempt.
#1 Updated by ben leinfelder over 9 years ago
A warning message about the required dependency not being met seems like the best option. Especially if it is integrated into the process such that you have the option of either downloading the dependencies when you try to open the kar or skip that step and try your luck. I think another level of "strictness" might be a little too confusing.
#2 Updated by David Welker about 9 years ago
The solution adopted is for modules that are OS-specific to be ignored if running on a different operating system. This is a decent solution for now, especially as the only OS-specific module at this point is apple-extensions.
In a future release, I hope to address this issue with services.
#3 Updated by Derik Barseghian about 9 years ago
Changing title and status to ER targeted to 2.3 -- you still cannot open a KAR when one of its module dependencies cannot be downloaded (e.g. unpublished, third-party). A warning dialog allowing you to live dangerously and open anyway, like suggested above, would be a convenient enhancement.
Note that the text explaining KAR strictness modes in KARPreferencesTab should reflect any changes.