Abandoned Scripts

MCroft said:

Or whatever the correct behavior is.

Click to expand...

Yep.

Step 1 is to establish the Scripts menu as having unique script names and the source of the supported versions.
Then Something scans the svn directories for scripts that are not in the menu. Then it looks for name conflicts and offers to delete the "rogue". Lots of fiddly work, unknown UI and trigger, and might be a fun project for a dev or a waste of time because adding documentation plus RTFM also solves the problem.

Please excuse my flogging a deceased equine, but I still maintain that the correct behavior is not to have forks with identically-named files.

Particularly in KoLmafia, where even having identically named files in separate folders can result in undesirable behavior, we do not want to have situations where a single filename refers to multiple files.

In the event that you attempt to checkout/update a project which adds a file that is already present in another project, I recommend that it fail with an informative error message, such as "Unable to add 'somefile.ash': file already exists in 'projectname'. To continue, delete 'projectname' and try again."

This would encourage users to do the right thing if a new project replaces an old one -- and encourage script authors to use unique names to avoid this situation.

(Henceforth using "project" to distinguish what you install from individual script files)

I'm warming up to Zarqon's sentiment. For OCD, we could rename the fork to "OCD-Cleanup".

Here's a suggestion for an install/update algorithm that avoids overwriting other project's files:

Since the name of a script is used in other scripts, I wish to avoid having to change all of the other scripts.

I would like to avoid the naïve user coming to complain that script X has stopped working and having to tell them to edit X to change some name to some other name or petition the author of X to do so.

I spent enough time as a professional Configuration Manager that I don't have to be sold on the benefits of unique identifiers. Perhaps some kind of versioning could be introduced in a way that certain references to ocd.ash will use ocd.1.ash if both it and ocd.ash are present?

In the situation I encountered it would have been helpful if the output from the SVN command, displayed in the gCLI, was also reflected in the session log.

Would a feature request along those lines be looked upon with favor?

Magus_Prime said:

In the situation I encountered it would have been helpful if the output from the SVN command, displayed in the gCLI, was also reflected in the session log.

Would a feature request along those lines be looked upon with favor?

Click to expand...

Which output? In general it is not a problem to add gCLI output to the session log. The mirror command is a workaround until KoLmafia is changed.

In particular the output from the svn delete command.

Magus_Prime said:

In the situation I encountered it would have been helpful if the output from the SVN command, displayed in the gCLI, was also reflected in the session log.

Would a feature request along those lines be looked upon with favor?

Click to expand...

Does r20587 scratch the itch?

Almost. I would ask that, if possible, the svn command itself would make it into the session log. E.g.: "svn delete bale-ocd".

With your change it puts which files the SVN command removed but not the project name. If it isn't reasonably possible what you changed is still much appreciated. Thank you!

Magus_Prime said:

Almost. I would ask that, if possible, the svn command itself would make it into the session log. E.g.: "svn delete bale-ocd".

With your change it puts which files the SVN command removed but not the project name. If it isn't reasonably possible what you changed is still much appreciated. Thank you!

Click to expand...

I expected this to be iterative so I see what I can do.

Magus_Prime said:

Almost. I would ask that, if possible, the svn command itself would make it into the session log. E.g.: "svn delete bale-ocd".

With your change it puts which files the SVN command removed but not the project name. If it isn't reasonably possible what you changed is still much appreciated. Thank you!

Click to expand...

r20589 a step closer?

It is perfection itself.

I'm thinking this has become overtaken by events.

The people who take over can pretty much make the decision as to whether to rename the script or not.

It is a Feature Request that svnrepo.json (which builds the KoLmafia Script Manager menus) be managed so that entries do not collide by trying to put the same named files in the same directory.

It is a Community Request that the new maintainers submit the repository location of the adopted script for inclusion in svnrepo.json and that they post in the existing thread. That post would announce the new repository, the new name, for a renamed script, and where to go for support.

It is a Feature Request that KoLmafia be modified to detect and warn, or prevent, the conflict created when two repositories provide the same named script. That said, given that I can be selfishly lazy at times, I'm not convinced I would implement that, since Don't Do That combined with a svnrepo.json that has no collisions also addresses the issue.

About overwriting each other's files...

What if we didn't copy files at all? When installing a project, don't copy files from /svn/<project>/ to /scripts, /relay, etc.

If we devise a way of using these projects from the gCLI/ASH/JS, we'll no longer need to worry about clobbering other people's files.

Edit: I'm still not sure what to do about OCD-Cleanup. Circumstances forced us to rename it. It's no longer a drop-in replacement, and requires an explicit install. Do we want to keep posting in the same thread for bale-ocd, where it will be hard to find under new replies?
What if Bale returns to us?

Maybe I'm overthinking it.

philmasterplus said:

About overwriting each other's files...

What if we didn't copy files at all? When installing a project, don't copy files from /svn/<project>/ to /scripts, /relay, etc.

If we devise a way of using these projects from the gCLI/ASH/JS, we'll no longer need to worry about clobbering other people's files.

Edit: I'm still not sure what to do about OCD-Cleanup. Circumstances forced us to rename it. It's no longer a drop-in replacement, and requires an explicit install. Do we want to keep posting in the same thread for bale-ocd, where it will be hard to find under new replies?
What if Bale returns to us?

Maybe I'm overthinking it.

Click to expand...

Imo you are way overthinking

Not copying the files is not an option.

Is OCD-Cleanup a script that users will want to migrate to or will they continue using OCD instead? If the latter then why are you publishing it? Otherwise there really is no use case for a user having both OCD-Cleanup and OCD installed unless you screwed with file formats, names or contents in an incompatible way.

Since you renamed it, they can co-exist. (In the case of the not renamed Universal Recovery users were just told to uninstall the old one first).

Assume that Bale is not coming back and no one is going to come along and decide to fork OCD again rather than try and work with the folks maintaining OCD-Cleanup.

Not copying has 2 problems:
1) you can still have the same filename in more than one place (directories within one script, or within multiple scripts). What's the rule for resolving such files? From CLI? From within a script that doesn't have that file in its repository? Script that does have that file in its repository? Script that doesn't, but imports another script that does?
How about having the same relay/ file from multiple sources? Execute one? (which?) All? In what order?
I think it can be done, but will require a lot of thought, work, and error-by-error improvements to get right.
Also, the same thing can mostly be done *with* copying, just copy from /svn/$project to /scripts/$project (I don't think the other main directories support reaching a nested file without specifying path the same way scripts/ does)
data/ seems like it *really* should have always been jailed per-script unless asking for another script's file, though.

2) You shouldn't want to handle any problems that clobber your "live" files becasuse "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 ... and then later have the one as-quick-and-simple-as-possible step that updates live files.

fronobulax said:

Not copying the files is not an option.

Click to expand...

It could be an option. We have to copy files because kolmafia looks only in scripts/, relay/, etc. What if kolmafia also looked inside (subdirectories of) svn/?

xKiv said:

you can still have the same filename in more than one place (directories within one script, or within multiple scripts). What's the rule for resolving such files? From CLI? From within a script that doesn't have that file in its repository?

Click to expand...

I don't know the details of KoLmafia's "module resolution" algorithm, but currently it walks recursively through scripts/ and relay/ looking for a script name. It makes file name clash a problem, with or without copying. I've seen two workarounds so far:

• Combine all code into one gigantic script, so that you minimize the chances of accidentally using a file name that another script might be using. For example, TourGuide bundles multiple small ASH files by resolving import statements, and combining them into one gigantic ASH file.
• Make sure that all your files have unique names. E.g. if you want to have a "support.ash", name it ocd-cleanup.support.ash.

Both are not ideal. But it's a behavior that many people have come to expect, and changing it would require planning and migration.

(I do wish it were different. If I want my project to contain a test.ash without clashing with other people's test.ash, putting it inside a philmasterplus/ subdirectory should just work. Currently it does not work because of the recursive lookup.

xKiv said:

You shouldn't want to handle any problems that clobber your "live" files becasuse "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 ... and then later have the one as-quick-and-simple-as-possible step that updates live files.

Click to expand...

This is why Not Copying is needed. You can't clobber files if you don't copy them in the first place.

philmasterplus said:

It could be an option. We have to copy files because kolmafia looks only in scripts/, relay/, etc. What if kolmafia also looked inside (subdirectories of) svn/?


I don't know the details of KoLmafia's "module resolution" algorithm, but currently it walks recursively through scripts/ and relay/ looking for a script name. It makes file name clash a problem, with or without copying. I've seen two workarounds so far:

• Combine all code into one gigantic script, so that you minimize the chances of accidentally using a file name that another script might be using. For example, TourGuide bundles multiple small ASH files by resolving import statements, and combining them into one gigantic ASH file.
• Make sure that all your files have unique names. E.g. if you want to have a "support.ash", name it ocd-cleanup.support.ash.

Both are not ideal. But it's a behavior that many people have come to expect, and changing it would require planning and migration.

(I do wish it were different. If I want my project to contain a test.ash without clashing with other people's test.ash, putting it inside a philmasterplus/ subdirectory should just work. Currently it does not work because of the recursive lookup.


This is why Not Copying is needed. You can't clobber files if you don't copy them in the first place.

Click to expand...

IMO, you continue to overthink, in the sense that you are describing problems that don't actually occur because there are solutions that exist and people are comfortable with. I too struggle with that and I have found that remembering that "just because something is possible, does not mean it is probable" helps me focus.

At the time SVN was implemented one directory, such as /scripts, could not hold multiple SVN repositories. That may be true in general or it may be that the devs chose a different architecture to avoid addressing that problem. You are welcome to code your own solution although I am not likely to be the one who commits it for you. Copying will continue because when a user updates a script the expect the new version to be available as soon as the update completes and with out further action on their part. Given the historical absence of name conflicts, not breaking that workflow/expectation seems to be more important than fixing an infrequent problem.

I question or don't understand your assertion about recursive lookup not working. Creating a subdirectory within scripts has long been a solution to both a Script Manager menu that is unwieldly and a proactive script writer who wants to avoid file name conflicts. Perhaps a Bug Report or Feature Request with instructions that demonstrate the problem?

In the decade that SVN has been around I have seen exactly one name conflict and I created it when I forked Universal recovery but did not rename it. Once I understand community interest and guidelines for svnrepo.json I expect I will delete the OBE UR entry which will make the problem go away.

You assert existing solutions to file name conflicts and namespace conflicts within files are not ideal. Consider the possibility that this is a case where Good Enough really is good enough.

philmasterplus said:

This is why Not Copying is needed. You can't clobber files if you don't copy them in the first place.

Click to expand...

If you ignore the part where I explained how your only copy can get clobbered.

fronobulax said:

You assert existing solutions to file name conflicts and namespace conflicts within files are not ideal. Consider the possibility that this is a case where Good Enough really is good enough.

Click to expand...

I'll let it pass then. As you said, file names conflicts have in practice have happened only twice in history--once with UR and once with OCD. Both were forks, which should be pretty rare. KoLmafia always has limited dev time, so we should not bother with such cases.

FWIW, all of my points stemmed from my understanding of how Python (pip) and JavaScript (npm) handle packages. Each package is installed in their own subdirectory (venv or node_modules). The package manager never copies a package's files to a shared directory‡, so a package never needs to worry about clobbering another package's files. And the package/module loader has no problem loading them by name.

(‡ Technically, some files do get created in shared directories like node_modules/.bin, but they're just 1-2 files.)

If there is a flaw in my understanding, please feel free to correct me.

xKiv said:

If you ignore the part where I explained how your only copy can get clobbered.

Click to expand...

If you did, it sailed right over my head. Could you please dumb it down a bit?