Cannot find bundle with Bundle.module

[jagreenwood]

I have a simple executable package that defines a resource bundle and tries to reference the bundle with Bundle.module.

When the executable is installed with Mint and then run, it throws an error Fatal error: could not load resource bundle because it is looking for the bundle in ~/.mint/bin/ alongside the executable symlink when it is actually located in the ~/mint/packages/... directory alongside the executable.

I did some testing and moving the bundle to ~/.mint/bin/ resolves the issue.

[yonaskolb]

What's your mint --version? There were some changes around this in the newer releases

[jagreenwood]

I was on 0.17.2 but updated to 0.17.5 and I've got the same issue.

Looking at the dynamically generated resource_bundle_accessor.swift source, I think it is looking for the bundle at

// For command-line tools.
Bundle.main.bundleURL,

I don't exactly know how the system treats running executables from symlinks, but in terms of looking for resources, it appears to not follow the link.

With the latest changes I see in 0.17.5, would it be reasonable to simply move all build artifacts to ~/mint/bin/ rather than create symlinks? I don't have the history of knowing why ~/mint/packages/ is important, apologies if that is a ridiculous suggestion.
I can make that change and PR it if that makes sense to do.

[jagreenwood]

@yonaskolb What are your thoughts on a fix for this? I'd be happy to contribute to a fix.

[yaroslavyaroslav]

I think this one is related to that: SwiftGen/SwiftGen#905

[yonaskolb]

@jagreenwood ~/.mint/bin was created here #216 as a location for the single "globally" installed version of a package. ~/.mint/packages is for all build artefacts for all versions.

I'm not sure how to best resolve this situation, but have 2 thoughts:

• these will still work if you use mint run ..., as opposed to using mint install ... and then running separately.
• we can't really just copy the bundles into /bin as they would collide with bundles from other executables (and maybe even different versions of those same bundles)