Open jagreenwood opened 1 year ago
What's your mint --version
? There were some changes around this in the newer releases
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.
@yonaskolb What are your thoughts on a fix for this? I'd be happy to contribute to a fix.
I think this one is related to that: https://github.com/SwiftGen/SwiftGen/issues/905
@jagreenwood ~/.mint/bin
was created here https://github.com/yonaskolb/Mint/pull/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:
mint run ...
, as opposed to using mint install ...
and then running separately./bin
as they would collide with bundles from other executables (and maybe even different versions of those same bundles)
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.