I'm thinking of a "script installer", in which newly-acquired scripts are automatically copied to the ..|Runtime|Python|poserScripts|ScriptsMenu folder

This would be of use to the less advanced Poser user, who has acquired a shiny new script. In trepidation they then go hunting through Windows Explorer for ten minutes to locate the right place to paste the script(s), in order to have the scripts show up in the Poser User Interface. Maybe they get it wrong. It would be nice to automate the install.

IN POSER:

The following PoserPython script can be used to detect the install folder of the running Poser, and print the path, and could be developed as a script-installer....

import poser
import os

scriptPath = os.path.split(poser.AppLocation())[0]
scriptPath = os.path.join(scriptPath, "Runtime", "Python", "poserScripts", "ScriptsMenu")

if os.path.exists(scriptPath):
    print scriptPath
else:
    msg = "The Poser ScriptsMenu folder cannot be found"
    dlg = poser.DialogSimple.MessageBox(msg)

OUTSIDE POSER:

However, running the above script requires the user to install the script in Poser first, which rather defeats the object. Since they already know how and where to install a script.

So my mind then turned to the idea of a "script installer" that would not require Poser to be running. A Windows .BAT file might do it. Include the .BAT in the folder with the new scripts, the user clicks on it, and the folder and its .py script(s) are sent to the proper ..|Runtime|Python|poserScripts|ScriptsMenu folder.

The problem is how to have the .BAT detect the correct path for Poser 11, when there could be many Poser.exe files on the system (Poser 2014, 11, 12). And when the target could be installed on C:\ D:\ or Z:\ etc, and under any curious folder name.

Before I look further a Windows-only .BAT files, is there a good cross-platform way to tackle the problem? Or perhaps someone has already solved the "help newbies install a Poser script" problem?

Learn the Secrets of Poser 11 and Line-art Filters.

Well, I wrote a basic Windows.BAT file as a starter. USE: Put it in the folder with your newly downloaded Poser 11 .PY scripts, then run it in Admin mode. It finds whatever the Windows OS is using as "Program Files", whatever drive that may be on. Then it finds there Poser 11 (whether installed to "Smith Micro" or "Poser Software") and finally it copies all the .PY files to the correct scripts folder, so they can be found when Poser is started.

@echo off

:: First we nicely size the .BAT file's console window.
Mode con cols=90 lines=25

:: Then we print a message for the user, in the console window.
echo Searching for your Program Files folders for Poser 11. Please wait for a few moments ....

:: Now we find the user's Windows OS Program Files folder, whatever drive they are using for the programs.
:: This assumes they do not have Poser 11 installed on an obscure network drive or some other weird place.
for /d /r "%ProgramFiles%" %%a in (*) do if /i "%%~nxa"=="Poser 11" set "folderpath=%%a"
:: If the folder has Poser 11 in the path, then we extract the folder path. This bypasses the need to do
:: wildcard coding to detect either the old \Smith Micro\Poser 11\ or the new \Poser Software\Poser 11\ folders.

:: The found folder path is passed to the new variable 'folderpath' - but this is only part of the path.
:: Therefore we also set up a new 'scriptsmenupath' hard variable, containing the rest of the required path.
set scriptsmenupath=\Runtime\Python\poserScripts\ScriptsMenu

:: Then we combine the two variables into one working Windows folder path.
set combopath=%folderpath%%scriptsmenupath%

:: Print the combined working folder path to the console window, to reassure the user.
echo %combopath%

:: When run as Admin, a .BAT file stupidly defaults its working directory to C:\windows\system32\ DURH!
:: Thus here we change the working directory back to the same folder in which the .BAT file resides.
cd /d "%~dp0"

:: Now we can do a copy operation, sending all the folder's .PY Python files to the Poser 11 ScriptsMenu folder.
:: Of course, a successful copy requires that the .BAT file is being run in Administrator mode in Windows.
xcopy "*.py" "%combopath%"

:: Prevent the .BAT file's console window from instantly closing.
PAUSE

Learn the Secrets of Poser 11 and Line-art Filters.

Why a batch file?
A user who is not able to start a script according to instructions should avoid computers. After all, this is not rocket science but absolute basic knowledge.

In general: How does the "stupid user" know how to execute a .BAT file and where to find it? If you can teach him that, then he can also find and execute a Python script.

(I generally don't think it's a good idea to counter non-knowledge with even more help. Imparting knowledge is always the better idea)

Of course I don't want to stop you from your project. I just think it is quite unnecessary.

Excellent idea, just include/drop the install file in the same directory as the python scripts and run

I always think that automation/install scripts follow a 10/90 rule where 10% of effort achives 90% of the functionality but the remaining 10% takes 90% of the time.

These are the thoughts I try to follow when automating a process like an install

1. Don't modify/delete a users existing files without their consent

2. Don't trash either the application or other peoples scripts

3. Use atomic operations where possible so its easy to revert if the script fails

4. Don't mess up the users hard drive with unnecessary files

Sure there are others, helps to be paraniod :)

Point 1 - Display files to be changed and use set /p to seek confirmation

Point 2 - More difficult, use unique file nameing conventions so less likely to overwite another persons files

Point 3 - Rename function is very powerful when building complex installs - generate new files in temp area and if all works ok at the end just rename file/directory. This is important if the program is running and may lock a file, easier a rename a directory than wind back many ops incase of a failure

Point 4 - Need to consider if version specific and also if user runs the script if no install exists

Just from a discussion point of view, Immediate thought on script is what what happens if more than one version of Poser install

For version specific installs the reg command might help (might be possibe to refine reg command line other otherwises a "for" + "findstr" might do the trick

To find current active version of Poser the "ftype" command, again I wondering if the for command can be used to pull this into an environ var

Thanks Ironsoul. Useful tips.

1. "use unique file naming conventions so less likely to overwrite another persons files" - yes, it might be useful for the .BAT to append a suffix to the copied .PY file(s). And thus prevent an overwrite if the files already exist.

2. "If user runs the script if no install exists" - yes, there should probably be an "Poser 11 not found" fallback message. That would be added, if I released it on Freestuff.

3. "what happens if more than one version of Poser install" - three versions could be supplied. It's just a matter of changing the "Poser 11" wording to Poser 12 or Poser 2014. An advanced user would do that, but it would be easier to supply three files each marked as _P11, _P12, _P2014.

4. Yes I thought of searching the Windows registry, but I wasn't sure what souped-up level of security paranoia level Windows 10 and 11 have for that. The above .BAT file handles the search quickly - and without need for a wildcard to detect either "Smith Micro" or "Poser Software" in the path - by splitting and then rejoining the Program Files path.

Learn the Secrets of Poser 11 and Line-art Filters.

Forum: Poser Python Scripting

Subject: Best way to help less advanced users to correctly install a Poser script?