Delay associated with running Pepys across network

[IanMayo]

When pepys-import or pepys-admin are run on the client network there is a 20 second delay before the python code starts.

I copied Pepys to the C: drive, and the apps opened with a delay of only around a second.

So, we should work with onsite technical support to provide local installs of Pepys.

In discussion today, we came up with this strategy:

1. Create "Update Pepys" script, which overwrites the local C:\Site Programs\Pepys folder with one from M"\tools\Pepys\current", then runs bin\install.bat"
2. Create script which creates shortcut to above script, called "Install updater", and puts it into the start menu
3. Invite Pepys users to run install updater from network location, then Update Pepys from their start menu

Then, on new updates, Pepys users will be invited to run Update Pepys from their Start menu

[robintw]

Are we expected to write these scripts? If so, will we be hard-coding the path to the network version of Pepys - or will that be provided in some other way (partly in case the network location changes, partly in case the network location is sensitive).

If we need to write new Powershell scripts to do this, then I am happy to do this before I leave - but will need to start work on it soon.

[IanMayo]

Thanks for that @robintw , but if @mew-nsc is ok with it, I'm happy for it to be prioritized at the next sprint review. I can apply a manual fix (copy/paste) in the near-term, it's only for a couple of users.

[IanMayo]

Pulling this item back into the backlog. I'd like us to consider a strategy for local deployments of Pepys - to overcome the delay in the pepys-import or pepys-admin starting. Ideally we'd have some way of the local install checking it's version against either the master install, or against the database version - which I guess would prompt the user to run Update pepys from the Start Menu.

[robintw]

A few short notes on this (we can discuss more in our call tomorrow if you want):

We can't just use the database version for comparison, as the database version only changes if we have a database migration, whereas we want to know whether there has been a change in the version of Pepys itself, which can happen without migrations being needed

I think the best way of doing this would be:

1. We store a path to the 'master' version in the Pepys config file. This would be the same path that they run Pepys from now (which is presumably mapped to a drive letter?)
2. On startup, it checks a single file in that master version to find out what version it is (it could be the __init__.py file in the main directory, which currently stores the version - or it could be elsewhere). That should be fairly quick.
3. If that version is different to the version of the code that is running, it gives an error and asks the user to upgrade.
4. The upgrade script is another entry in the Start Menu. It simply runs a recursive copy of the pepys folder from the master location to the local location. We'd need to think a bit about how to run this: my first thought was just a batch script doing a copy command, but it would need to know the master location which requires reading the config file. So, I thought we could run it through Pepys itself, using the Pepys bundled Python...but then we'd be trying to overwrite the Pepys files and Pepys python while it was running, which would end badly. I suspect the best option would be to combine both: we run a Python script that gets the master location and then we capture the output of that script and use it as input to a standard copy command. (Alternatively we could do some Powershell magic to read the config file with Powershell - I'll have a look and see how easy that is).

How does this sound @IanMayo?

[IanMayo]

That's all good, thanks @robintw .

Potential alternate solutions for the "process wanting to update itself" could be:

• Include paths for local and master installation locations in the config file. On "Run update", call "update" from the master location, pushing Pepys to the local location
• Create a script in the Startup folder, and ask the user to logout/login. The local Pepys won't be running on the login.
• When we put shortcuts into the Windows menu, the Pepys-Admin shortcut points to the local instance, but Update pepys shortcut points to the master instance

I agree about the database version.

[IanMayo]

I've just tested this @robintw - and it worked fine.

The verbose setting on copy is a bit of a pain. Is there a way of showing a progress indicator instead?

Hmm, also - one thought. I think we should try to ensure that we update the version file right at the end. In that way, if an update fails, it can be restarted. Currently, if an update fails once the version file has been updated, then Pepys will think it's on the new version.

Aah, hold on. I've just run upgrade again - and it has repeated the upgrade. I wonder why we're not checking the version. Aaah, I know. We currently check the version in pepys-admin and pepys-import. Once they have warned the user to upgrade, then we're ok with the update just happening.

Does that sound right?

[robintw]

The verbose setting on copy is a bit of a pain. Is there a way of showing a progress indicator instead?

Unfortunately I've tried all sorts of ways of getting a sensible progress indicator (including most of the ones here) but none of them give us what we want. Most of them either fail entirely, or give us a progress bar per-file, whereas we want one overall progress bar. I think we're probably stuck with either using the verbose mode, or having no output at all while the copy takes place.

Hmm, also - one thought. I think we should try to ensure that we update the version file right at the end.

That's a good idea - I'll switch to two copies, one for everything except the version file, and one for the version file.

Does that sound right?

Yes I think so - and it simplifies the logic of the upgrade script a lot.

[IanMayo]

That's all great, thanks @robintw . Let's keep the verbose setting - to avoid a delay that could look like things have frozen.