Scripts updating & general script questions

R

rockenrog

Well-known member
Hi experienced users,
Some general scripts questions. If there is an answer to these questions in the forum, please link me to it.
  • When uninstalling PI for updating to new release, are all the scripts in the PI program/src/scripts folder removed, then reinstalled (except 3rd party scripts)?
  • How do I know if a script is 3rd party or not?
  • If I put a 3rd party Ver 0.8 of NormalizedScaleGradient script into a different folder (than src/scripts) PI did not seem to find it after I restarted PI. I had to manually load it. Is that normal when restarting? Now it is part of the 1.8.8-8 as Ver 1.0.
  • What are some good sources for finding 3rd party scripts?
  • Does Regenerate in PI check anything related to 3rd party scripts?
Thanks for your comments,
Roger
 
It has been suggested:

"In such cases, I would try to delete updates.xri *), before PI is started and press RESOURCES/Updates/Check for Updates. In that case, Pi can not find the history of updates and forces a complete re-scan."

Instead of deleting this file (it is a lone file in your PixInsight installation directory)- just rename it.
It did work for me! Pretty cool trick if this is a legit way to do a refresh scripts.
(I didn't even restart PI)

-adam
 
when you install a new version of PI, the new scripts directory is only holding the scripts that ship natively with PI.

on OSX and probably also linux, you can just rename the folder containing old version of PI, thus making room for the new installation and preserving all of the stuff you had before, which you can just copy back into the new version's installation folder. on windows... well, i don't know, i have very little experience with windows. because of the registry it might not work to rename the PI installation folder.

i've seen my list of repositories get reset as after a major upgrade, so you probably have to go back in and re-add any 3rd party repositories after a major upgrade.

speaking of which, repositories are one place where 3rd party scripts come from. i guess it's not easy to tell if a script is a 3rd party script without a little digging; the copyright notice inside the javascript files will probably not say Pleiades Astrophoto on a 3rd party script. the EZ suite scripts are all called "EZ- something" and install in a hierarchial menu in the Scripts menu. but generally speaking there's no easy way to tell if a script came from Juan or came from someone else.

i only know of a couple 3rd party repositories but i'm sure there are more:

HVB's scripts: http://www.skypixels.at/pixinsight_scripts.html (see that page for details of the repository URL)
the EZ suite: https://darkarchon.internet-box.ch:8443/ (this is the actual repository URL)

what adam is describing is a way to reset and cause PI to re-download all the updates that Pleiades has released, both modules and scripts. i don't think i've ever tried moving/deleting the updates.xri file while i had 3rd party script repositories loaded so i'm not 100% sure that 3rd party scripts would be redownloaded after moving/deleting that file. seems like they probably would be though since PI doesn't really differentiate between a Pleiades repo and a 3rd party repo.

i think what Regenerate does is just scans thru the src/scripts directory and finds any scripts that PI itself has not added to its menus, and adds them. so for instance if you had put your version 0.8 of NSG in src/scripts and then hit regenerate, it would appear in the scripts menu across PI restarts.

rob
 
I was bold enough to try, and it did redownload the latest scripts from 3-party repositories. Neat trick.
As long as 3-rd party developers always had a live repository- this seems cool.

On another note, when I hit the "update" button manually- it seems like the user should be able to override the last version downloaded logic in some way. If a script goes missing or something-you can't fool it to redownload again. But manipulating this file as an emergency force doesn't seem too bad.

When I uninstalled, the old scripts directory remained I think. Maybe I was lucky? It is possible to make this an uninstall option? (I have no idea, just asking.)
Something like this would save lot of heartache, as it would become a part of the "process" to install a new version.

-adam
 
A few important concepts...

i've seen my list of repositories get reset as after a major upgrade, so you probably have to go back in and re-add any 3rd party repositories after a major upgrade.
Click to expand...

This cannot happen since at least version 1.8.7 of PixInsight if I remember well, or maybe 1.8.6. All third-party repositories are preserved when you install a new version of PixInsight. Third-party repos are those not starting with "xxxx://pixinsight.xxx", or with a subdomain of a pixinsight.xxx domain, where xxx can be one of "com", "org", "net" and "software" (for now).

on OSX and probably also linux, you can just rename the folder containing old version of PI, thus making room for the new installation and preserving all of the stuff you had before, which you can just copy back into the new version's installation folder. on windows... well, i don't know, i have very little experience with windows. because of the registry it might not work to rename the PI installation folder.
Click to expand...

Besides a couple of entries created by the installation package, PixInsight does not use the Windows registry at all. Anyway, instead of renaming the folder where PixInsight has been installed (which is a system protected folder), you can simply make a backup copy of the required files on any folder under your home directory. Scripts are just plain text files, so there are no problems or complications to copy them anywhere.

There is no need to delete or rename the updates.xri file under normal conditions. You can always force a complete reinstall of all installed scripts by running PixInsight with the --default-scripts command line argument:

Linux:
PixInsight --default-scripts

macOS:
/Applications/PixInsight/PixInsight.app/Contents/MacOS/PixInsight --default-scripts

Windows:
"C:\Program Files\PixInsight\bin\PixInsight.exe" --default-scripts

i think what Regenerate does is just scans thru the src/scripts directory and finds any scripts that PI itself has not added to its menus, and adds them. so for instance if you had put your version 0.8 of NSG in src/scripts and then hit regenerate, it would appear in the scripts menu across PI restarts.
Click to expand...

Feature Scripts > Regenerate does not look for new scripts, but just for the ones already featured. You have to use the Add button to find new scripts. Or use the foolproof --default-scripts argument described above.
 
ok thanks for the clarifications, i didn't realize the repository behavior had changed in 1.8.8-7. recall that i've been using PI for like 11 years now!

rob
 
Thanks to all you 'veterans' for the great information and advice to me, a much newer user. I appreciate your passion for excellence and continued improvements in the program. Everyone does.
Note to Roger: Now I need to study the files/directories so I clearly understand the above.
Roger
 
Last edited:
Just a followup...
I found in HBV's scripts (link above) the advice for users to add the link: https://www.skypixels.at/HVB_Repository/ to PixinsightI: Resources/Updates/Manage Repositories/. Then the 23 scripts there will be kept up to date.
I have had that link put in Manage Repositories already, and all 23 of the scripts are installed as expected.

EZ suite is new to me. I will take a look.

Thanks to all...
Roger
 
Juan Conejero said:
There is no need to delete or rename the updates.xri file under normal conditions. You can always force a complete reinstall of all installed scripts by running PixInsight with the --default-scripts command line argument:

Linux:
PixInsight --default-scripts

macOS:
/Applications/PixInsight/PixInsight.app/Contents/MacOS/PixInsight --default-scripts

Windows:
"C:\Program Files\PixInsight\bin\PixInsight.exe" --default-scripts



Feature Scripts > Regenerate does not look for new scripts, but just for the ones already featured. You have to use the Add button to find new scripts. Or use the foolproof --default-scripts argument described above.
Click to expand...

I am very sorry to circle back to this topic. But I need a clarification.
I physically deleted a 3rd party script from my directory.
Then I ran the PixInisght executable with the command line options of --default-scripts

I expected Pixinsight to visit the repositories and download the scripts. This is did not happen.

Please help.
Thanks,
Adam
 
I am very sorry to circle back to this topic. But I need a clarification.
I physically deleted a 3rd party script from my directory.
Then I ran the PixInisght executable with the command line options of --default-scripts

@Juan Conejero
I expected Pixinsight to visit the repositories and download the scripts. This is did not happen.

Please help.
Thanks,
Adam
 
Last edited:
Hi Adam,

The --default-scripts command line argument does not download any scripts. It just scans the standard PixInsight/src/scripts folder for scripts with valid #feature-id directives and regenerates the Script main menu item to include all of them. This is the description of this argument that you can read if you execute PixInsight --help:

Code: 
--default-scripts

      Reset the set of featured scripts. After scanning the src/scripts
      installation directory looking for scripts, the core application will
      create entries for all valid scripts found under the Script menu. Other
      scripts that could have previously been featured will be discarded.
 
Ah... I see.
This is good in the case that all scripts exist.

Is there is easy way to force visiting respositories and grabbing 3rd party scripts (overriding any logic that PixInsight thinks about being up-to-date)?

Now I need my deleted script! LOL

-adam
 
Is there is easy way to force visiting respositories and grabbing 3rd party scripts (overriding any logic that PixInsight thinks about being up-to-date)?
Click to expand...

Under normal conditions this should never be necessary. I have tried to reproduce the problems that have been reported about installed scripts not being featured and I have been unable to do so on all platforms. We have special sandbox repositories on our server that we use to test our update system. I am quite sure that all of the reported problems fall into one of these categories:

- The 3rd-party repositories have not been updated to advertise installation packages for the latest version of PixInsight. When this happens, the 3rd-party scripts are not available through our update system, so they get 'lost' when the user installs a new version. Obviously we have no control on these problems. Of course we always offer our help to 3rd-party developers, including questions about update repositories and how to keep them synchronized with new PixInsight versions.

- An antivirus application has prevented normal operation of our updater program. For example, this can prevent inclusion of updated scripts under the Script main menu item if the files in question have been quarantined, removed or renamed, or if the file cannot be accessed. Again, these problems are out of our scope.
 
i'm still at a loss to understand this. the problem seems to arise when someone installs a new version of PI using the installer from the distribution server, which means that the old installation is removed, and thus any installed scripts are also removed.

however, people that find themselves in this situation invariably have the javascript files for the scripts they are missing in src/scripts. this implies then that PI visits the script repository, downloads the files, and the PI updater unpacks them and installs them. however, when PI is restarted, the scripts are not featured in the menu. so does this mean that the check for version compatibility happens at the end of the process (meaning, the only thing that checks the version is the code that updates the list of scripts?)

i understand the need for 3rd party scripts to be kept up-to-date with respect to PI, but are PJSR version compatibility issues really something that occurs with every release of PI? there are some very old scripts that still work OK...
 
i understand the need for 3rd party scripts to be kept up-to-date with respect to PI, but are PJSR version compatibility issues really something that occurs with every release of PI? there are some very old scripts that still work OK...
Click to expand...

No, not at all. Unless a script uses a new feature or functionality of PJSR, there is no reason for it to fail under new versions. I make big efforts to preserve compatibility scrupulously from version to version, and in the rare cases where there are breaking changes, I try to inform about them when a new version is released. Anyway, if a script does not work on a particular version that doesn't mean that it cannot be installed. So this cannot be the problem in this case.

so does this mean that the check for version compatibility happens at the end of the process (meaning, the only thing that checks the version is the code that updates the list of scripts?)
Click to expand...

The update system knows nothing about product versions, neither script/module versions nor versions of the core application. It just executes the sequence of actions that have been specified by the update repository when the update has been downloaded. Update repositories must publicize update packages providing information about the range of PixInsight versions where each update can be installed. For example, this is the entry corresponding to a recent update in the updates.xri file of our standard repository at https://pixinsight.com/update/1.8.8-12/:

XML: 
   <platform os="all" arch="noarch" version="1.8.8-12:1.8.8-12">
      <package fileName="20220104-script.zip"
               sha1="656826d7d281f6dcb467561f60572b9242cffd75"
               type="script"
               releaseDate="20220104">
         <remove> <!-- ### WARNING ### DO NOT PROPAGATE ### -->
            src/scripts/JohnMurphy
         </remove>
         <title>
            NormalizeScaleGradient script version 1.4.5 (bugfix)
         </title>
         <description>
            <p>
               This update installs a new version of the NormalizeScaleGradient script, written by John Murphy. This is a cumulative bugfix release for PixInsight 1.8.8-12:
            </p>
            <ul>
               <li>
                  Fixed a scrollbar bugfix. This bug occurred if a target filename was long enough to need a scrollbar. It would initially display OK, but if the script was closed and then reopened, the target list would be populated but without the scrollbar.<br/>
               </li>
               <li>
                  Modify the filename prefix so that files can be listed in weight order.<br/>
               </li>
               <li>
                  Fixed potential star detection crash. A loop index limit could sometimes have a floating point value. This could occasionally  cause a Matrix index to be beyond the allowed range.<br/>
               </li>
            </ul>
            <p>
               ________________________________________________________________
            </p>
            <p>
               Copyright &copy; 2019-2022 John Murphy<br/>
               Copyright &copy; 2003-2022 Pleiades Astrophoto.
            </p>
         </description>
      </package>
   </platform>

As you can see, the version attribute of the platform element says that this update can only be installed on version 1.8.8-12 of PixInsight. This package will be invisible for other versions.

Here is another example from our standard update-db repository:

XML: 
   <platform os="all" arch="noarch" version="1.8.8-6:1.8.9">
      <package fileName="20200822-resource.zip"
               serverURL="https://pxiupdate-15c2b.kxcdn.com/"
               sha1="f69a1b669293970f198169ac9ed18067dea1e71c"
               type="resource"
               releaseDate="20200822">
         <title>
            StarNet Neural Network Weights Databases - 2020/08/22 Release
         </title>
         <description>
            <p>
               This package installs the necessary weights files for the StarNet module, written by Nikita Misiura, available since PixInsight core 1.8.8-6 Ripley. This package provides the RGB and grayscale weights databases. Released 2020 August 22.
            </p>
            <p>
               Copyright &copy; 2003-2020 Pleiades Astrophoto S.L. All Rights Reserved.<br/>
               Copyright &copy; 2018-2020 Nikita Misiura. All Rights Reserved.
            </p>
         </description>
      </package>
   </platform> <!-- os="all" arch="noarch" -->

This package will be seen by all PixInsight versions from 1.8.8-6 to a future 1.8.9 version. I have written this entry this way because the package installs database files that are not going to change for some time, so I don't need to bother creating a new entry for each new version of PixInsight, at least for now.

I hope this clarifies some concepts about update repositories and how the update system works internally.
 
it seems like version= "from:to" is too restrictive then based on your efforts to keep PJSR backward compatible. unless version="from" is valid syntax representing only a minimum version, it seems like developers are forced to come up with an "end" version of PI that either does not exist or is the current latest version. maybe they don't know that a nonexistent version can be specified as the second argument to version=.

if version= can only take two arguments strictly bounding what versions are compatible, maybe version= should be split into two tags, version= and min_version=. that way a developer could say "ok, this script has some feature that only appeared in PJSR in 1.8.8-9 and i don't expect it to break ever (min_version="1.8.8-9", version=""). later (say in -13) maybe for some reason a function prototype changes, or the feature is is removed from PJSR and so the script developer could say min_version="1.8.8-9", version="1.8.8-9:1.8.8-12". in this case min-version is redundant so maybe the repository would just say version="1.8.8-9:1.8.8-12".

i still don't understand why, if version strings like "version=1.8.8-6:1.8.8-11" appear in a script repository (in other words, what you have identified as the likely problem upthread), why PI 1.8.8-12 seems to download and install the scripts and then not feature them. i can't understand why so many people are having problems with scripts after upgrading PI, and all they end up having to do is ask PI to find them again.
 
I use the following scripts from https://www.skypixels.at/HVB_Repository/
GAME
2DPlot
PSF Image

I have https://www.skypixels.at/HVB_Repository/ in the Manage Update Repositories list.

I added each of the above scripts to my Pixinsight/src/scripts folder.
I used Add in Feature Scripts... for each script to get them in the Script list.


I have a MacBook Pro so when I upgraded from 1.8.8-11, I put the whole Pixinsight folder in the trash before I did the update to 1.8.8-12.

After the update to 1.8.8.12, the GAME, 2DPlot, and PSF Image scripts were not in the 1.8.8.12 Script list.

I had to use Add in Feature Scripts... for each script to get them in the 1.8.8.12 Script list.


Is this the expected behavior?
 
it wouldn't seem so, especially since the updates.xri file for hartmut's repository has:

<platform os="all" arch="noarch" version="1.0.0:9.9.9">

which means it does not need any update for 1.8.8-12.

rob
 
What confuses me is that on my MacBook Pro the updates.xri file is contained in the Pixinsight folder. When I move the Pixinsight folder(containing updates.xri) to the trash, how can the new version of Pixinsight know anything about the particular scripts I downloaded from hartmut's repository.

Jack
 
You must log in or register to reply here.
Back
Top