Migration prompt on first launch wizard about polymc HOT 17 CLOSED

mmc is portable on macos, windows, and linux. the official linux .deb chooses to install multimc in in /opt/multimc, but that by no means is the same on all linux OSs or install methods

from polymc.

I mean on windows the multimc directory is the directory you download, on Mac and Linux it's a set folder no matter where you install the program or run it from ~/.local/share/polymc and the .app folder on Mac iirc

This makes it possible to know where multimc and polymc instances are on any Mac and Linux system

from polymc.

I mean on windows the multimc directory is the directory you download, on Mac and Linux it's a set folder no matter where you install the program or run it from

on macos, yes thats correct, on linux that is not
like I said, if you use the .deb to install (so on debian/ubuntu most users will use this) it will install to /opt/multimc
if you use the binary tarball (the tar.gz) that can go LITERALLY ANYWHERE, it gives you MultiMC folder already setup

from polymc.

I mean on windows the multimc directory is the directory you download, on Mac and Linux it's a set folder no matter where you install the program or run it from

on macos, yes thats correct, on linux that is not
like I said, if you use the .deb to install (so on debian/ubuntu most users will use this) it will install to /opt/multimc
if you use the binary tarball (the tar.gz) that can go LITERALLY ANYWHERE, it gives you MultiMC folder already setup

That's the programs files, they can be put anywhere, opt for example, but users can't write to opt, mmc and poly always put their user data and instance data in local share because of this.

EDIT: On top of that, MMC only officially supports being installed with their updating script which does use local share, so that's a known path, and polys would be known by the poly program at setup

from polymc.

That's the programs files, they can be put anywhere, opt for example, but users can't write to opt, mmc and poly always put their user data and instance data in local share because of this.

incorrect again, when you use the binary tar.gz, the instances are created inside the root MultiMC folder wherever the user placed them
for example, I decided to download the tar.gz, extract it into my Downloads folder, and now all instances are located at ~/Downloads/MultiMC/instances, its fully portable

from polymc.

EDIT: On top of that, MMC only officially supports being installed with their updating script which does use local share, so that's a known path, and polys would be known by the poly program at setup

still incorrect... MultiMC's builtin updater works fine from any folder. it does not use the local share unless thats how it was initially setup to use (which I have shown it is not already, except for the deb)

from polymc.

What I'm saying is: The binary and/or library files found in the .deb and .tar files from mmc and poly can be put anywhere, system or user folders, they are portable, this is true.

But mmc/poly need a USER write-able folder for the instance and config data because mmc/poly doesn't run as root, this is configured with INSTDIR env.

For MMC this has always been INSTDIR="${XDG_DATA_HOME-$HOME/.local/share}/multimc" from any official packaging source and afaik any unofficial ones too, which means we relatively know the location of this data as long as any user didn't change it themselves

And poly still follows this, additionally since this proposed migration process would be part of poly, poly would be running and INSTDIR for poly would already be known as a variable we can use.

from polymc.

What I'm saying is: The binary and/or library files found in the .deb and .tar files from mmc and poly can be put anywhere, system or user folders, they are portable, this is true.

But mmc/poly need a USER write-able folder for the instance and config data because mmc/poly doesn't run as root, this is configured with INSTDIR env.

For MMC this has always been INSTDIR="${XDG_DATA_HOME-$HOME/.local/share}/multimc" from any official packaging source and afaik any unofficial ones too, which means we relatively know the location of this data as long as any user didn't change it themselves

And poly still follows this, additionally since this proposed migration process would be part of poly, poly would be running and INSTDIR for poly would already be known as a variable we can use.

Noooooooo read what I said, I'm sorry but you are wrong. the official tar.gz binaries do NOT put anything in .local AT ALL. Try it it out because clearly you do not believe me and are not reading what I have written

from polymc.

From the looks of it (in launcher/Application.cpp);

• lin-system uses ~/.local/share/polymc
• lin-nodeps and Windows use the application directory
• MacOS uses the Data folder in the .app

from polymc.

IMO just let user pick via file manager and show some common paths. If user picks via file manager it will also work on sandboxes like flatpak or appimage which isolate it. Though I could theoretically add the multimc local share folder to flatpak permissions

from polymc.

I was going to make a seperate issue but I think it is close enough to this so ill add my suggestion here:

We should make a way to modulary import worlds and mods from the official launcher and multimc. Possibly extensible for other launchers such as gd, curseforge and pvp clients.

Approach

Have a page in settings to migrate mods and worlds from the official launcher and multimc. Possibly show in the installation stage similar to #49. However I think just in the settings menu would work better.

The official launcher has defined file locations and should not have issues being imported. However multimc and other launchers may be portable and will require the user to define a folder location.

If possible also be able to import modded instances from the official launcher.

Alternatives

• external application to manage migration eg: "polymc migrator"
• just having a migration guide on the wiki

I will design some mockups soon for how this functionality could work.

from polymc.

from polymc.

Afaik official launcher doesnt have multiple instances, so how would migrating it work? Create an istance with data from official launcher?

from polymc.

Likely create multiple versions based on the versions the user has installed in their official launcher each version having there files. Or having a solution possibly linking to #71 and share between the instances.

from polymc.

This shouldn't be super hard to implement, however, I don't know how to programmatically reload the confiuration, instance files, etc. after they've been copied from PolyMC.

We also need a warning that it may result in some configuration being lost. Or, should we ONLY migrate instances and icons?

from polymc.

This isn't something I am interested in doing because copying files manually is trivial and I don't think it's worthwhile to implement a whole automated system for this when we could just have a section on the wiki titled "Migrating from MultiMC" that just says essentially "copy these files, rename this file, and you're done". If someone wants to implement this then fine but I don't think it's a good use of time personally.

from polymc.

I am going to close this issue, There doesn't seem to be any interest in doing this we have a wiki page on it and as PolyMC plans to evolve this may not stay feasible.

from polymc.