Add modpack support

[rsg245]

Packwiz, modrinth (mrpack) and default zip archives

[mindstorm38]

I would also like to be able to install Curseforge.

We also need a nice syntax, I propose something using the start command, like:

• portablemc start curseforge:<project-id-or-slug>
• portablemc start modrinth:<project-slug>

[rsg245]

I would also like to be able to install Curseforge.

We also need a nice syntax, I propose something using the start command, like:

* `portablemc start curseforge:<project-id-or-slug>`

* `portablemc start modrinth:<project-slug>`

pmc - alias to portablemc

pmc modpack import --url {modrinth/curseforge cdn url}/--path {local path} --modpack-slug {podpack-alias}
pmc modpack export --modpack-type {modrint/native} {name}.mrpack/{name}.zip/{name}.tar.gz/{name}.tar.bz

[mindstorm38]

I actually like this idea; we should give the path to the --mc-dir also;

[mindstorm38]

I want to work on this feature, but I'm wondering how to keep the start command simple...

For example, if we use this pmc modpack subcommand, as a user I would like the start to be easy, but for know it will require to use something like pmc start forge|fabric:<the version chosen by the modpack>, and so I don't find this very very pleasant. We could use something like pmc start modpack: and let's say it use some kind of metadata to know the modpack description... It still requires multiple commands to launch the game, which I don't really like!

But at the same time we cannot really, or it would not be that easy, to use the start command alone, like I was describing in a previous post (pmc start modrinth:<project-slug>), because modpacks are really intrusive and will basically destroy the --mc-dir. One solution would be to prevent such problem by checking if there is already a modpack. I find this a good solution.

The last thing is that I really like the idea of being able to export modpacks, in this case it will really need to be its own subcommand!