This makes it harder for problems in the updating process to affect the
current instance. Network issues, for instance, will no longer put the
instance in an invalid state.
Still, a possible improvement to this would be passing that logic to
InstanceStaging instead, to be handled with the instance commiting
directly. However, as it is now, the code would become very spaguetti-y,
and given that the override operation in the commiting could also put
the instance into an invalid state, it seems to me that, in order to
fully error-proof this, we would need to do a copy operation on the
whole instance, in order to modify the copy, and only in the end
override everything an once with a rename. That also has the possibility
of corrupting the instance if done without super care, however, so I
think we may need to instead create an automatic backup system, with an
undo command of sorts, or something like that. This doesn't seem very
trivial though, so it'll probably need to wait until another PR. In the
meantime, the user is advised to always backup their instances before
doing this kind of action, as always.
What a long commit message o.O
Signed-off-by: flow <flowlnlnln@gmail.com>
By now, it's a recurring pattern of wanting to restrict aborting in
certain situations. This avoids further code duplication, and adds a
signal that external users can hook up to to respond to such change.
Signed-off-by: flow <flowlnlnln@gmail.com>
These help us keep track of relevant metadata information about
overrides, so that we know what they are when we update a pack.
Signed-off-by: flow <flowlnlnln@gmail.com>
While working on pack updating, instance naming always gets in the way,
since we need both way of respecting the user's name choice, and a
standarized way of getting the original pack name / version.
This tries to circunvent such problems by abstracting away the naming
schema into it's own struct, holding both the original name / version,
and the user-defined name, so that everyone can be happy and world peace
can be achieved! (at least that's what i'd hope :c).
Signed-off-by: flow <flowlnlnln@gmail.com>
This avoids them getting deleted when the worker thread exits, due to
thread affinity on the created thread.
Signed-off-by: flow <flowlnlnln@gmail.com>
We were not propagating the '--demo' flag in the legacy launcher,
unconditionally setting the 'demo' parameter to false.
Signed-off-by: flow <flowlnlnln@gmail.com>
Using `Collections.emptyList()` doesn't allow us to later append stuff
into that list. Use an empty `ArrayList` instead.
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
