Brendan Hansknecht said:
How do you build a rust glue package if it depends on
../../roc_std/src/lib.rs
?). You don't really want many copies of the same files, but might be stuck with that and versioning pains if we package src.
I'm not worried at all about the "many copies of the same files" part when it comes to glue :big_smile:
however, this does raise a general question about what to do with ..
paths for static strings/byte lists in the context of bundling :thinking:
I'd never thought about this scenario until now, but my immediate thought is that of course the bundle should automatically include those
because otherwise in the general case, you download the bundle and it doesn't build
that's no good!
however, the paths are an interesting challenge because:
..
paths, and then copy the assets over to whatever path we rewrite it to. A downside of this is that today the bundling process is very simple, (just put all the relevant files in a tarball, done) which means it can be performed on systems that have roc
installed. This design would mean giving up that potentially useful property. Also, rewriting would mean that you couldn't independently hash the original source files yourself and verify them, because the hash roc
would generate would be against the rewritten files. Also if you looked into your cache, you'd find that the files there are different from the source files that were put into the bundle...
in these import paths gets ignored when reading out of the downloaded cache, and then copy the files over according to that rule. That would work, but now if you go into your cache and hand-edit files, some of the paths work differently than how they look like they would...
in import paths, and say if you want the behavior we have in RustGlue.roc
you have to use symlinks. This would be particularly inconvenient for application authors who have no intention of ever bundling their code, but who want to use ..
like how we are in RocGlue.roc
today.I guess we could also disallow bundling things with ..
in their paths
of course, a downside of that is that if you didn't get an error sooner, you might not realize you'd included one until you went to make a release, which might be an unpleasant surprise
Yeah, so bundling the compiled asset means we dont need to deal with that. Though it guess it is plausible for this to get hit in a regular package instead of a glue specific one
yeah this has to be solved regardless of glue
10 messages were moved here from #ideas > specifying glue
file in package module by Richard Feldman.
moved because this is a currently-unhandled edge case in the compiler :big_smile:
Last updated: Jul 06 2025 at 12:14 UTC