Feature Revert 20743?

[fronobulax]

See https://kolmafia.us/threads/svn-update-does-not-move-files-in-local-copy.26043/page-4#post-162486 and https://kolmafia.us/threads/20743-w...-directory-and-file-name-not-just-file.26094/ for background and related. discussion.

Prior to r20743 it was assumed that any file in the script name space had a unique name. This meant that a user could install a script, move that script to a different location and the script would still be updated via SVN. One motivation for moving scripts was because the script menus had no organization other than the underlying file system so moving scripts to subdirectories reduced visual clutter while still allowing the script to be selected and run.

r20743 changed this. SVN would only install or update a file if it was in the directory the author expected. This allowed JavaScript writers to use common names for files without collisions with other scripts.

Since I feel like I broke something while helping someone I am not really happy with the results.

Trying to have it both ways, by adding a preference, would mean that some scripts would not install or work based upon the preference. Trying to detect the situation and prompt the user will not work for users who are not running the GUI (unless someone smarter than I jumps in). Reverting will break scripts currently deployed or under development which, at the very least, would require that KoLmafia actually enforce the unique name convention and detect violations. Keeping it breaks updates for some users and should lead to some discussion about how to declutter menus (and perhaps the file system).

I am certainly capable of coming up with a proposed rework of the relationship between SVN, runnable scripts and the file system but that could be more disruptive than helpful.

Comments? Suggestions? Guidance?

 

[xKiv]

I think that preventing scripts from overwriting each other's files is more important than organizing menus and files in scripts/.
If we can also work on something else that will (eventually) do one or both of those, that would be greater, of course.

 

[MCroft]

Are you still considering MINE-crafting as a model to give scripts that want it (and they all will, eventually) a way to say "this is my stuff, and nobody can write over it but me?" I thought we were working towards a hybrid model where a script had some assurance that their stuff wasn't overwrite able by someone else.

edit: moved stuff to the other split-off thread.

 

[fronobulax]

I have not figured out how to deconflict MINE-crafting, opting in or out, who is in charge and what happens when things get broken outside of mafia. We are close to unenforced (by code) MIME-crafting now and the example of any user who chooses to move or rename where something is in /scripts after installation illustrates the issues to be resolved.

I am reluctant to tell a user or a scripter "Don't Do That" in cases where they used to be able to do that or they expect to be able to do that because of how things work elsewhere.

On the feature at hand, we have taken a small step towards MINE by respecting directory names on install and update. I'm still wrestling with adding a preference that undoes the change and then warns the user they may have a problem. I don't know which is worse - not doing it and telling script movers - "I'm sorry but that is now broken and you really don't want to do it anymore" or doing it and repeatedly explaining to users why the script they just tried to install doesn't work.

 

[MCroft]

I have not figured out how to deconflict MINE-crafting, opting in or out, who is in charge and what happens when things get broken outside of mafia. We are close to unenforced (by code) MIME-crafting now and the example of any user who chooses to move or rename where something is in /scripts after installation illustrates the issues to be resolved.

I am reluctant to tell a user or a scripter "Don't Do That" in cases where they used to be able to do that or they expect to be able to do that because of how things work elsewhere.

On the feature at hand, we have taken a small step towards MINE by respecting directory names on install and update. I'm still wrestling with adding a preference that undoes the change and then warns the user they may have a problem. I don't know which is worse - not doing it and telling script movers - "I'm sorry but that is now broken and you really don't want to do it anymore" or doing it and repeatedly explaining to users why the script they just tried to install doesn't work.

Well, at the top level, a script name is a unique thing. blah_blah_blah's_sooper_duper_duplicator.ash, or whatever. We could say that anything under a directory namedblah_blah_blah's_sooper_duper_duplicator is protected and only blah_blah_blah's_sooper_duper_duplicator.ash updates can change it.

If you don't switch to this model, everything works like the current public namespace.

We might want to search the protected namespace first, because that would even allow you to include your own version of zlib.ash, for good or for ill. Or the user could refer to it by path, and we'd only look where they said (e.g. dir/utils/my_util.ash).

 

[taltamir]

My suggestion is that instead of reverting things to the wild west of letting scripts overwrite each other's files.
instead allow reorganizing using a file
/settings/username_script_menu.txt
which is used to record user made changes to the menu without moving or renaming actual files.

currently there is
Script>Script Manager
under script manager put "Organize Scripts" button.
click on it will open a simple GUI to reorganize the menus which will be done via updating the file /data/script_menu.txt

as for format for that file... I am thinking
full-filename [tab] command [tab] user-defined-filename

user-defined-filename only exists if user chose to rename or move the script in the gui

command can be: default, change, favorite, hide
default = show script normally. but obey rename field if not ""
favorite = show at the top with a star
hide = do not show this in gui. allow scripts to define files or directories to hide by default

for example:
/scripts/autoscend/combat/auto_combat.ash [tab] default [tab] /scripts/autocombat
please pretend that [tab] is an actual tab