1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
use PathBuf;
/// Where a bundle's executable artifact comes from.
///
/// `BundleSource` is **host-internal**: it never crosses the C ABI and is not part
/// of the frozen ABI surface. It is threaded through [`BundleLoader::load`] so a
/// loader can serve a bundle from an on-disk directory, from in-memory VM source
/// text, or from raw artifact bytes.
///
/// [`BundleLoader::load`]: crate::loader::BundleLoader::load
///
/// # Loader support
///
/// - The **native** loader supports [`BundleSource::Path`] only. There is no clean,
/// portable in-memory `dlopen` on Windows/macOS, so `Code`/`Bytes` are rejected
/// by the native loader.
/// - VM loaders (Lua, JS, Python) gain real [`BundleSource::Code`] support, and the
/// .NET loader gains real [`BundleSource::Bytes`] support, in a later phase. Until
/// then every loader rejects the variants it does not yet implement with a
/// structured error.
///
/// # No bundle directory for non-path sources
///
/// [`BundleSource::Code`] and [`BundleSource::Bytes`] carry no bundle directory, so
/// directory-relative provisioning — such as prepending the bundle directory to the
/// Lua `package.path` or the Python `sys.path` — does not apply. These sources are
/// **single-file only**: the artifact must be self-contained, with no sibling files
/// resolved relative to a bundle directory.