Implementing multiple destinations for mcopy donwloads

[Crafter-Y]

Something like this is needed for itzg/docker-minecraft-server#3658.

This PR aims to add the ability to specify mcopy destinations per resource.

For example

mc-image-helper mcopy --to=.  "./downloaded<https://raw.githubusercontent.com/itzg/docker-mc-proxy/refs/heads/master/build/setup-user.sh"

and

mc-image-helper mcopy --to=. "./downloaded/one<https://raw.githubusercontent.com/itzg/docker-mc-proxy/refs/heads/master/build/setup-user.sh,./downloaded/two<https://raw.githubusercontent.com/itzg/docker-mc-proxy/refs/heads/master/build/install-packages.sh"

The prefixes are additive to the --to flag.

--to is now always used as the base path/workdir for mcopy.
If there is a absolute path given, like in the overrideDestOrder test, the base path gets overwritten
If there is a relative path, it will be based of the --to path

Any overwrite down the line should work like that:
--to -> File listing -> actual file

The --to flag is now optional. But it should error if there is no destination for any given resource.

--to gets overwritten by any destination given by a resource.
--to gets overwritten by any destination given by file listings
file listing destinations get overwritten by any destinations given by a resource

All of this does not work with manifests. If a manifest is specified by --manifest-id or --scope, a --to path must be used and there is an (handled) error if it gets overwritten.

[Crafter-Y]

Hi @itzg, I know some java. but things might be a bit hacky. I ran the tests to ensure everything is still working and I added some new ones

[itzg]

The --to flag is now optional. But it should error if there is no destination for any given resource.

Sorry, I meant to preemptively point out that I would like to keep the --to flag required and where it will be the base for relative paths in the per destination values. As such that can also be where the manifest is placed. For example "/data" would be the base destination and users can give paths relative to that like "config".

[Crafter-Y]

I reintroduced --to as you requested.

I have to admit, that I don't know how these manifests work. Since the unit tests are passing, I assume everything is working. Could you please verify that it does? I also added another unit test for that.

[itzg]

Thanks. Yeah, I'll take a closer look at the manifest part. Basically they're a standard json structure I'm doing with a file listing and other data of interest for each feature, like modpack versions.

[itzg]

Thanks for the update

[itzg]

--to gets overwritten by any destination given by a resource.
--to gets overwritten by any destination given by file listings
file listing destinations get overwritten by any destinations given by a resource

I'm actually thinking the entry prefixes are additive to the --to and to the outer prefix when --file-is-listing. I'm suspecting the unit test scenario confused things a bit since they were absolute paths there, which would override the --to.

[Crafter-Y]

The prefixes are additive to the --to flag.

--to is now always used as the base path/workdir for mcopy.
If there is a absolute path given, like in the overrideDestOrder test, the base path gets overwritten
If there is a relative path, it will be based of the --to path

Any overwrite down the line should work like that:
--to -> File listing -> actual file

[itzg]

The prefixes are additive to the --to flag.

--to is now always used as the base path/workdir for mcopy.

If there is a absolute path given, like in the overrideDestOrder test, the base path gets overwritten

If there is a relative path, it will be based of the --to path

Any overwrite down the line should work like that:

--to -> File listing -> actual file

Yes, this sounds more correct.

[Crafter-Y]

Thanks. Looks like we're good to go now?

[itzg]

I believe so. Thanks! I'll give it one more look next time I'm at my computer and get it merged.

[itzg]

Release in https://github.com/itzg/mc-image-helper/releases/tag/1.49.0, so now can be updated at

https://github.com/itzg/docker-minecraft-server/blob/593c94ad9481620750aabc1821c81a6758417346/Dockerfile#L51

and image side script changes can be made. More info here

https://docker-minecraft-server.readthedocs.io/en/latest/misc/contributing/development/#using-development-copy-of-tools