Abandoned Scripts

Kolmafia code is over a decade old and maintained by volunteers with various levels of expertise. There are a number of things that would be done differently if there was a clean slate reboot that are not worth doing otherwise. To mention a few, if I had a project to create KoLmafia 2.0 from scratch, I probably would not host it at SourceForge and not use SVN as my version control system. I would use a build system, such as Maven, that managed external compile and run dependencies better. I would not invent a scripting language but would focus on support for some other language, for example, JavaScript. I might even consider a plugin API instead of a scripting API. I would ask whether script distribution and update really needs to be a KoLmafia feature, and so on. But none of these are easy if there is also a requirement to keep KoLmafia working and the degree to which they are necessary is a matter of opinion, tempered by costs and benefits.

It is reasonable to extrapolate from package managers but they are by no means the only modern solution to versioning, distribution and dependency issues.
 
Last edited:
philmasterplus said:
If you did, it sailed right over my head. Could you please dumb it down a bit?
Click to expand...
Uh ... all of this?
> "something went wrong" while updating (merge conflict, network down halfway through download, power failure, ...). You should have as much conflict resolved as possible "somewhere else" where you can restart the update process cleanly without breaking anything that's actually being used ...

Because /svn/project/ are made of files, and are also where you are supposed to make local changes (which can create merge conflict on update).
(pristine copies are *also* just files)


BTW, AFAIU, npm also has two-stage update of packages (first into a temporary directory, then replace the actual destination), and that's without managing local changes.

AND, even if you completely solve managing packages, you still need to look at how scripts are automatically hooked into CLI (currently by filename) and relay browser (also by filename). Otherwise I suspect you will stil run in similar problems, just with better diagnostics possible.
 
xKiv said:
Because /svn/project/ are made of files, and are also where you are supposed to make local changes (which can create merge conflict on update).
(pristine copies are *also* just files)
Click to expand...

Ah...ok. I wasn't aware that people were actually doing development inside /svn/projectname. Thanks for clarifying.
 
philmasterplus said:
Ah...ok. I wasn't aware that people were actually doing development inside /svn/projectname. Thanks for clarifying.
Click to expand...
See Revision Merging. It is the preferred solution for local modifications that are to be preserved, if possible, when the author makes updates.

It is also the easiest place to do development on my published scripts. My svn tools already understand where to commit and get history, differences, etc.
 
bumping this while I have a few days to do some small fixes.

My initial thought on an approach is adding optional fields to the metadata in svnrepo.json.

I'm thinking we might want:
  • conflictsWith: [list, of, scriptnames]
  • replaces: [list, of, scriptnames]
  • replacedBy: singleScriptName or special value "None" ("None" means obsolete, no replacement, like scripts for old areas..)
behaviors:
  1. on load check consistency (no circular "replacedBy", all replacedBy have "replaces", update A->B->C to just A->C, bi-directional conflicts, notify of installed conflicts, obsolete, replacedBy...)
  2. on request to install script w/"conflictWith": check for installed conflicts & (if so) tell user to remove "conflict" before installing this script, allows user to continue.
  3. on request to install script w/"replaces": check for installed replaced script & tell user to remove old script first, allow them to install anyway.
  4. on request to install script w/"replacedBy" : suggest replacement instead, but allow user to continue.
The next version would offer to actually do those things instead of just notifying.
 
My knee jerk reaction is overengineered but that is the pot calling the kettle black.

Unless we are going to make KoLmafia into something like an app store where things are curated I'm thinking I could be happy with just conflicts.

KoLmafia presumably could build a list of scripts locally installed via SVN and have the names and directories they end up in. If mafia ever detects that there are two SVN installed scrips that would write files of the same name into the same directory then it should tell the user and refuse to install or update while the conflict exists. Make the user choose to uninstall one.

Having pondered this I no longer feel that KoLmafia has an obligation to maintain access to an abandoned script via the KoLmafia Scripts menu. Detect the conflict and make the user resolve it.

Mafia devs should clean up the scripts menu so there are no conflicts probably choosing the actively maintained script as resolution.
 
I agree with frono. It feels too elaborate.

Using a single JSON file to dictate conflicts and replacements is difficult because KoLmafia scripts are not maintained by a single organization. Since everyone is publishing their own scripts, it would be hard to keep svnrepo.json up to date.

For example, OCD-Cleanup (maintained by me) currently works fine when installed side-by-side with Bale's OCD Inventory Control. What if OCD-Cleanup wants to add a script file that causes it to conflict with OCD Inventory Control? Would I have to request a patch to svnrepo.json and wait for the mafia devs to update it? It would be cumbersome for both parties involved.

For conflicts, frono's suggestion seems more appropriate. Though I would understand if no one attempts to implement such a complicated feature.
 
In Ye Olden Days updates to svnrepo.json were maintained by Bale. People were asked to submit changes and periodically bale would have someone commit them. It worked well when all scripts in svnrepo.json were being actively maintained and had a thread at kolmafia.us which was the only expected source of support. Those days are not now.

You can traverse the svn directory to get a list of directories (that correspond to installations) and pretty much anything in one of those directories that is not a .svn directory or dependencies.txt will generate the name and path of a file that install or update will add or modify. Make a list and check for uniqueness and you have a static conflict detector. That IMO could be enough.

If I stop getting mad at Me, Robot tedium maybe I should just code that up.
 
could certainly scale back to "conflicts". Right now it is centrally controlled, same as the list of entries, so I'm not too worried about it, especially if that's a non-enforced but just informational option. That would also cut down on the self-checking.

What I was looking for was some way to say "don't stop supporting Bales OCD, but tell the user if they should use OCD-Cleanup instead."

Maybe it's less complex. Maybe we just have an "askBefore" property and we add a line to Bale's OCD that says "This script is supported, but not maintained. You may wish to install OCD-Cleanup instead." Abort/Continue (where the quoted text is the value of "askBefore" and if it's blank, don't ask.

We can also add a "thisScript installs into the same directory as thatScript" Abort/Continue command as a default check.
 
MCroft said:
could certainly scale back to "conflicts". Right now it is centrally controlled, same as the list of entries, so I'm not too worried about it, especially if that's a non-enforced but just informational option. That would also cut down on the self-checking.

What I was looking for was some way to say "don't stop supporting Bales OCD, but tell the user if they should use OCD-Cleanup instead."

Maybe it's less complex. Maybe we just have an "askBefore" property and we add a line to Bale's OCD that says "This script is supported, but not maintained. You may wish to install OCD-Cleanup instead." Abort/Continue (where the quoted text is the value of "askBefore" and if it's blank, don't ask.

We can also add a "thisScript installs into the same directory as thatScript" Abort/Continue command as a default check.
Click to expand...
We (KoLmafia devs) are advertising Bale's OCD, not supporting it or endorsing it.

We can manually detect and resolve conflicts in svnrepo but we have no control or awareness of scripts that are installed but not advertised.

So the programmatic solution to just report conflicts and let the user decide how to resolve them seems most reasonable to me. That would still be useful even if svnrepo was deprecated.

The advertising policy - what is added to or deleted from svnrepo - seems to be a different issue. Scripts are included there either because the author requested or dev felt the script contributed to the general good and should be advertised.

At this point I would suggest maintaining svnrepo so that there are no conflicts within it. It seems that someone who wants the original will still get it until they opt in to replacing it.
 
fronobulax said:
We (KoLmafia devs) are advertising Bale's OCD, not supporting it or endorsing it.

We can manually detect and resolve conflicts in svnrepo but we have no control or awareness of scripts that are installed but not advertised.

So the programmatic solution to just report conflicts and let the user decide how to resolve them seems most reasonable to me. That would still be useful even if svnrepo was deprecated.

The advertising policy - what is added to or deleted from svnrepo - seems to be a different issue. Scripts are included there either because the author requested or dev felt the script contributed to the general good and should be advertised.

At this point I would suggest maintaining svnrepo so that there are no conflicts within it. It seems that someone who wants the original will still get it until they opt in to replacing it.
Click to expand...
Hmm. I get the conflict issue. I think we agree there.

The issue I think keeps coming up and should be solvable is that (for example):
  1. A dev of a script stops updating it.
  2. KoL makes an incompatible change (e.g. "Potion of Temporary Gr8ness" name change)
  3. Someone forks the script and makes a replacement.
At that point, the user has no way of knowing that there's a relation between A and A-prime. All s/he knows is that the script is broken and it doesn't have an update available.

Is there a way we can approach that problem? I think it's probably more common than directory-level-conflicts, which I haven't actually heard of happening (maybe they do, idk).
 
MCroft said:
The issue I think keeps coming up and should be solvable is that (for example):
  1. A dev of a script stops updating it.
  2. KoL makes an incompatible change (e.g. "Potion of Temporary Gr8ness" name change)
  3. Someone forks the script and makes a replacement.
At that point, the user has no way of knowing that there's a relation between A and A-prime. All s/he knows is that the script is broken and it doesn't have an update available.

Is there a way we can approach that problem? I think it's probably more common than directory-level-conflicts, which I haven't actually heard of happening (maybe they do, idk).
Click to expand...

Moving projects under the LASS organization on GitHub seems like a decent solution to combat the social problem (i.e. developer burnout and abandonment). Since multiple users in LASS have commit or admin-level access to their projects, other people can step in even if a primary maintainer drops out.

Disclaimer: I have recently joined LASS but I don't really know how it's administrated. I assume it operates on "common sense" basis.

Edit: Was trying to compare GitHub with SourceForge but realized that I don't know much about SourceForge anyway.
 
MCroft said:
Hmm. I get the conflict issue. I think we agree there.

The issue I think keeps coming up and should be solvable is that (for example):
  1. A dev of a script stops updating it.
  2. KoL makes an incompatible change (e.g. "Potion of Temporary Gr8ness" name change)
  3. Someone forks the script and makes a replacement.
At that point, the user has no way of knowing that there's a relation between A and A-prime. All s/he knows is that the script is broken and it doesn't have an update available.

Is there a way we can approach that problem? I think it's probably more common than directory-level-conflicts, which I haven't actually heard of happening (maybe they do, idk).
Click to expand...

1 - Not our problem.
2 - Not our problem.
3 - Not our problem until someone makes a request/decision to include the replacement in svnrepo and the original is already there.

I can think of two or three cases where the creators of an A-prime chose not to publicize its existence on KoLmafia.us even though A was "published" here. I am willing to detect conflicts for a user who knows the super secret handshake and has access to A-prime but beyond that it is not a KoLmafia problem.

Again I say:

Mafia should inform the user of file name conflicts for installed scripts (but not take or prevent any action based upon that information).

If the editor of svnrepo knows that A and A-prime both exist in the file then the descriptive text in the file should be edited appropriately OR the author of A-prime should be encouraged to change the name so that A can be deleted from svnrepo and users who opt in to using A-prime renamed as A will be told of the conflict.

There is actually no way I can think of to know that A-prime exists and is intended to replace A unless the author of A-prime tells us so. Since installing scripts with different repositories or different names from the same repository is an opt in process the user can certainly accept some responsibility.
 
FWIW it amuses me to write code for a simple, well defined problem, so I will probably have something soon that parses the installed SVN directories and generates a list of installed scripts. I will probably look for duplicates in that list and make a cli command that checks for conflicts. This will amuse me and provide a foundation for anything someone else wants that might involve acting on conflicts and a GUI.
 
OK, I'll leave it alone. I still think there's a user pain point that we could address, but I don't want to step over what you've got in mind and you feel strongly about this.

I was thinking a developer checksvn command might be useful, if that's the kind of thing you're considering.
 
You must log in or register to reply here.
Back
Top